What goes into a hero run? A list of terms and concepts

Back to the main BWG page

A "Hero Run" is a very particular kind of performance test. It has two competing goals:

• Demonstrate the file system's capacity to move bulk data. Show the file system in its best possible light.
• Honestly report the file system's performance. Avoid setting unrealistic expectations for the file system's users.

This set of terms and definitions is focused on one particular style of test. Similar sorts of details will be gathered elsewhere for alternative tests. This test uses IOR to generate a load on a Lustre file system. The amount of data moved divided by the time it takes gives a data rate for the file system. For a well constructed test meeting the two criteria above, this number, also called the file system's bandwidth, characterizes the file system as a whole.

A POSIX-based IOR test runs on one or more client nodes and has these characteristics:

• file-per-process (as opposed to single-shared-file)
• block size - The amount of data a task will move (writing and or reading) over the course of the test.
• transfer size - The amount of data moved in a single POSIX system call (write() or read()).
• node count - How many clients are participating in the test?
• task count - Or equivalently, how many tasks per node? The task count = node count X tasks per node.
• stride - Help me out here.
• segment size - I'll have to review the IOR source before I can say what this is.

The HPC system as a whole, including its file system, needs to be understood in detail. It has many components that need to be specified:

• How many actual disks get combined into one volume, also known as a Logical UNit or LUN?
• How many LUNs are gathered into a particular OST?
• How many OSTs are on each OSS?
• What is the nature of the storage controller?
• How many OSS are there?
• What is the network topology?
• What is the network type?
• How is a client node constructed: buses, NUMA, etc)

There are user settings to consider and document:

• Stripe count

Similarly, there are administrative configuration details:

• System dirty write limit
• Per-OST dirty wite limit
• RPCs in flight
• Small file prefetch
• read ahead tunings

One should document the environment of the test:

• What system and what facility is this?
• The name of the file system
• The OS type and version (servers and clients)
• File system type and version (server and clients)
• Controller BIOS version
• IOR version