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_d...
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<mailto:John.Bent@seagategov.com>> wrote:
On Jun 20, 2017, at 1:04 AM, Harms, Kevin
<harms@alcf.anl.gov<mailto: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