fio 3.38

dd measures single-threaded sequential throughput and usually measures the page cache while doing it. fio measures what actually determines whether storage feels fast.

The two flags that matter

fio --name=randread --rw=randread --bs=4k --size=4G \
    --numjobs=4 --iodepth=32 --direct=1 --runtime=30 --time_based

--direct=1 bypasses the page cache. Without it you are benchmarking RAM, which is why so many published numbers are absurd.

--size larger than available RAM, for the same reason.

Reading the output

read: IOPS=142k, BW=555MiB/s
  clat percentiles (usec):
   | 50.00th=[  210], 95.00th=[  383], 99.00th=[  668], 99.90th=[ 2114]

The percentiles are the interesting part. Half of requests completed in 210 microseconds; one in a thousand took over 2 milliseconds.

That tail is what makes a system feel inconsistent, and an average would never show it.

Job files, for repeatability

[global]
ioengine=libaio
direct=1
size=4G
runtime=60
time_based
group_reporting

[seq-read]
rw=read
bs=1M
iodepth=8
stonewall

[rand-read]
rw=randread
bs=4k
iodepth=32
numjobs=4
stonewall

stonewall makes each job wait for the previous one so they do not compete for the device.

Where it earns its place

Comparing I/O schedulers on your own hardware rather than adopting advice measured on someone else’s. Checking a VPS delivers the storage performance it advertised. Establishing a baseline before things feel slow later.

Ways to fool yourself

Test against a file on a mounted filesystem. Writing to a raw block device destroys what is on it.

Compressing filesystems turn fio’s default zero-filled data into almost nothing. Use --refill_buffers on ZFS or Btrfs with compression.

Thermals. NVMe drives throttle when hot, and a 30-second test may never reach the temperature a real workload sustains.

Our fio guide covers the methodology properly.

Verify Your Download

Source releases are on GitHub. Most distributions package it.