Just for our future reference:

LANL used to run a script and push a ton of environmental info (including all sorts of file system metrics) into their benchmark measurements:
https://github.com/fs-test/fs_test/blob/master/utilities/scripts/env_to_db.tcsh

Here is the DB schema they used:
https://github.com/fs-test/fs_test/tree/master/results_db/schema

John

On Jun 23, 2017, at 9:43 AM, John Bent <John.Bent@seagategov.com> wrote:


On Jun 20, 2017, at 1:04 AM, Harms, Kevin <harms@alcf.anl.gov> wrote:


 Just my 0.02$ here, but I think the usefulness of the IO-500 would be to get the details of the how the storage system is tuned and what tuning options were used when running the job. Reporting of say all the Lustre/GPFS tuning parameters for a given storage system would be nice to know. For example, an IOR test done using the exact same compute system and storage system would give different results if it was GPFS was configured with a 256 KiB block size as opposed to a 8 MiB block size.

 I think people submitting "optimized" results with the result setup documented and all of the storage/FS configuration documented is more useful than trying to converge on a set of run rules.

Thanks Kevin,

I’ve been sending a flurry of emails while on the plane and some of this I’ve already discussed which is that we absolutely are in agreement with you that the value is to collect and document performance tuning and IO patterns that maximize storage performance.  In terms of your point about it being more "useful than trying to converge on a set of run rules,” I think we are also in agreement.  That is definitely the value.  Converging on the set of run rules however is the means to the end.  We believe we will have more much participation and much better collection of useful community information if we turn it into one of the 500’s.

Thanks,

John