fio Storage I/O Benchmark
fio is the standard storage benchmark, reproducing arbitrary I/O patterns to report IOPS, bandwidth, and latency percentiles. Results hinge on block size, queue depth, direct I/O, and SSD steady-state preconditioning.
fio (Flexible I/O Tester), created by Jens Axboe, is the standard tool for benchmarking storage performance on Linux and other systems. It can reproduce almost any I/O pattern through a rich set of parameters, making it indispensable for evaluating SSDs, NVMe drives, RAID arrays, network and cloud block storage, and filesystems. Because it can mimic the exact access pattern of a target application, fio bridges the gap between vendor datasheet numbers and what software will actually see.
What It Measures
fio reports IOPS (I/O operations per second), bandwidth (MB/s or GB/s), and detailed latency statistics including average, percentiles, and the full distribution. It separates read and write results and can report completion-latency and submission-latency breakdowns, distinguishing time spent waiting for the device from time spent in the kernel. These metrics together characterize a storage stack's throughput, responsiveness, and tail behavior under a precisely defined workload.
Methodology
A fio job specifies the access pattern (sequential or random), the read/write mix, block size (for example 4KB for random transactional I/O, 1MB for sequential streaming), I/O depth (queue depth), the number of jobs (parallel threads), the I/O engine (such as libaio or io_uring), and whether to bypass the page cache with direct I/O. fio runs the defined workload against a file or raw device for a set time or data volume and aggregates results. Realistic measurement requires preconditioning SSDs to steady state, because a fresh drive performs far better than one in long-term use, and using direct I/O to exclude misleading cache effects.
How to Interpret Results
Match the test pattern to your workload: random 4KB tests reflect databases and transactional systems, while large sequential tests reflect backups, logging, and media streaming. Read IOPS and bandwidth for capacity, and latency percentiles, especially p99 and p99.9, for responsiveness under pressure. Higher IOPS and bandwidth and lower tail latency are better. Always note queue depth, because IOPS scales with it while latency rises; report the operating point that matches production rather than the deepest queue that maximizes a headline IOPS number.
Limitations
fio measures the storage stack in isolation under a synthetic pattern, which may not match an application's real, mixed I/O behavior. Results depend heavily on configuration, caching, filesystem, and SSD steady-state, so naive runs can mislead, often by reading from page cache or testing fresh-out-of-box SSD performance that degrades dramatically later. It does not capture application-level effects like fragmentation accumulating over time or contention from other tenants on shared cloud storage. Use fio to characterize devices precisely, then validate with application-level benchmarks.