The following rules should ensure a fair comparison of the IO-500 results between systems and configurations. They serve to reduce mistakes and improve accuracy.

1. The latest version of io500.sh in GitHub must be used and all binaries should be built according to the included build instructions.
2. All required phases must be run and in the same order as they appear in the io500.sh script.
3. Read-after-write semantics: The system must be able to correctly read freshly written data from a different client after the close operation on the writer has been completed.
4. All create phases should run for at least 300 seconds; the stonewall flag can be used as an optional convenience to help
5. For SC19: The stonewall flag must be used and must be set to 300.
6. There can be no edits made to the script beyond changing the allowed variables and adding commands to configure the storage system (e.g. setting striping parameters).
   • For example, there can be no artificial delays added within the script such as calling ‘sleep’ between phases.
   • No edits are allowed to the utilities/io500_fixed.sh scripts.
   • You may not overwrite any parameters that are set in utilities/io500_fixed.sh.
7. The file names for the mdtest and IOR output files may not be pre-created.
8. You must run the benchmark on a single storage system.
9. You must configure the batch scheduler to allocate the ranks in blocks, e.g. if you are running with five ranks per client node then rank 0-5 must be placed on Node0 and 6-10 on Node1. You should verify the appropriate placement. This ensures the proper shifting in IOR.
10. All data must be written to persistent storage within the measured time for the individual benchmark,e.g. if a file system caches data, it must ensure that data is persistently stored before acknowledging the close.
11. Submitting the results must be done in accordance with the instructions on our submission page.
12. If a tool other than the included pfind is used for the find phase, then it must follow the same input and output behavior as the included pfind.
13. Please also refer to the README documents in the github repo.

Please send any requests for changes to these rules or clarifying questions to our mailing list.

Inside the io500.sh script you can make the modifications as indicated by the script, in particular these are:

1. In the setup_directories() function, change in which directory to run and set directory options (e.g. using tools such as lfs_setstripe or beegfs_ctl to specify different stripe size for the IOR easy directory and the IOR hard directory) Each of the four main phases (IOR easy and hard, and mdtest easy and hard) has a subdirectory on which these various options can be set; however, additional subdirectories within these subdirectories cannot be created.
2. In setup_paths() set the MPI arguments.
3. In setup_find(), you can choose the application that performs the find.
4. In extra_description(), you can add all the variables about the system information; this is useful when conducting many runs. While we query this information as well in the web submission, the web submission will read any value from the script.
5. Running with a stricter semantics such as O_DIRECT is allowed.
6. In the setup_ior|mdtest_easy|hard functions you can set the arguments for running the benchmarks. Details of allowed options are provided inside the script. As a rule of thumb, the hard benchmarks tolerate only options that do not change the access pattern. The easy patterns allow more changes as the intention is to show best-case performance (without explicit caching).

Please email the mailing list or the steering board for any clarifications.