fio Disk Testing: Archived NF5280M5 SSD Example

1. Purpose and scope

fio is a configurable I/O workload generator for measuring IOPS, bandwidth, latency and workload stability. The source describes single-drive comparison with a specification sheet and an NF5280M5 local-SSD example. Match the actual drive, OS, engine and test conditions; its historical “13 engines” list is not a fixed capability count for every fio build. It names sync, mmap, libaio, posixaio, SG v3, splice, null, network, syslet, guasi and solarisaio among its examples.

Run only against authorized, disposable test data and quiesced workloads. Stopping applications does not make arbitrary writes safe. The random-write example below overwrites its named file; changing a filename to a raw device can destroy live data. Confirm target, free space, backup and contention before a benchmark.

2. Historical downloads and installation

The source links these old packages; their compatibility and availability must be checked before use:

English references: fio-2.1.10.tar.gz.zip; libaio-devel-0.3.109-13.el7.x86_64.zip.

Extract the outer ZIP first, then upload/extract the Linux source archive. Install the appropriate libaio support/development package if building/using that engine. From the extracted source directory:

./configure
make && make install

Source inspection commands, with ASCII dashes corrected:

fio -v
fio --enghelp

3. Source parameter reference, clarified

Parameter	Meaning	Example / qualification
--name	Job/test name; required to identify the job.
--filename	Test file(s) or device(s). Colon can separate multiple filenames.	A raw-device write can destroy data.
--directory	Directory prefix for test files; otherwise the working directory applies.	/mntdir/seq_read/1M is the source example.
--ioengine	I/O engine supported by the build and target.	Source examples mention libaio, rbd; rbd is specifically for Ceph RBD.
--direct	Request direct/unbuffered I/O where supported.	1 bypasses the normal page-cache path; not every hardware cache.
--rw	read, write, rw, randwrite or randrw, as listed in the source.	The later command example also uses randread.
--rwmixwrite / --rwmixread	Write/read percentage for a mixed job.	Specify the intended complementary mix; source recommends setting one.
--bs	I/O block size, with suffixes such as k or m.	Source examples: 8k, 1m.
--size	I/O region/work amount, with size or percentage syntax as supported.	Source examples: 1M, 1G, 100%; not limited to filesystem-only targets.
--numjobs	Number of cloned jobs; processes or threads depend on configuration.	Tune to workload/CPU; physical-core count is a source heuristic, not a universal limit.
--iodepth	Requested in-flight I/O per job.	Source example 16. The source threshold 32 is workload-specific; synchronous engines do not gain queue depth above 1.
--runtime	Maximum runtime in seconds.	Source example: 300.
--ramp_time	Warm-up before measured statistics.	Source example: 10 seconds.
--time_based	Continue the workload for runtime, repeating the I/O region as needed.	This differs from stopping after one pass through size.
--group_reporting	Report grouped job statistics.
--thread	Use threads instead of separate job processes.	It does not guarantee lower overhead for every workload.
--output	Write report output to the specified file.	This is an output filename, not just a directory.
--pool	Ceph storage pool for the rbd engine.
--rbdname	RBD image name for the rbd engine.

4. Run and interpret a controlled test

The source says to remove test files manually after use, distinguish sequential/random/mixed jobs, and examine read/write results separately. Delete only the known test files. fio can run under nohup; if --output is specified, read that report file. nohup.out instead captures remaining stdout/stderr; it is not automatically the primary report in that case.

Tune numjobs and iodepth to the target and observe achieved queue depth/latency; larger settings can worsen latency after saturation. The source mentions fio 3.7 as a historical option and links 2.1.10; neither is a recommendation for the current latest release.

The two original command examples are preserved:

fio -filename=/root/iopstest/test -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=4k -size=10G -numjobs=50 -runtime=180 -group_reporting -name=rand_100read_4k

fio -filename=/root/iopstest/test -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=4k -size=10G -numjobs=50 -runtime=180 -group_reporting -name=rand_100write_4k

Both use psync, depth 1, 50 threaded jobs, a shared 10G filename region and runtime 180. They do not set time_based, so 180 is a limit rather than a guaranteed measured run duration. The shared filename also means jobs can overlap the same region. These are source workloads, not universally appropriate SSD qualification settings.

5. Source results

The source reports read 135714 IOPS and write 160491 IOPS for its NF5280M5 local-SSD case. Compare results only with matching block size, access pattern, queue depth, drive preconditioning and other specification conditions. IOPS specifications often use random workloads and bandwidth specifications sequential workloads, but the actual datasheet defines the test. A lower random-workload bandwidth is not by itself a defect.

IOPS means I/O operations per second. For fixed-size operations, approximate payload bandwidth is IOPS × I/O block size, with consistent byte units. Here bs is I/O block size, not the RAID stripe width; keep MB/s and MiB/s distinct.

English references: fio project documentation.