Everyone reaches for dd if=/dev/zero of=test bs=1M count=1024 to measure disk speed, then squints at the number and pretends it means something. It doesn't. dd measures sequential bulk throughput with whatever caching the kernel feels like doing that afternoon. It tells you nothing about the thing that actually makes your database feel slow: latency.

ioping is the missing tool. Written by Konstantin Khlebnikov, it does for storage what ping does for networks — fires individual I/O requests at a path or device and reports per-request latency. Install it from your distro (apt install ioping, brew install ioping, pacman -S ioping).

The default invocation is exactly what you'd hope:

$ ioping /var/lib/postgresql
4 KiB <<< /var/lib/postgresql (ext4 /dev/nvme0n1p2): request=1 time=89.2 us
4 KiB <<< /var/lib/postgresql (ext4 /dev/nvme0n1p2): request=2 time=72.4 us
4 KiB <<< /var/lib/postgresql (ext4 /dev/nvme0n1p2): request=3 time=104  us (slow)
^C
--- /var/lib/postgresql (ext4 /dev/nvme0n1p2) ioping statistics ---
3 requests completed in 265.9 us, 12 KiB read, 11.3 k iops, 44.1 MiB/s
generated 3 requests in 2.45 s, 12 KiB, 1 iops, 4.89 KiB/s
min/avg/max/mdev = 72.4 us / 88.6 us / 104 us / 12.9 us

Real random-read latency. No buffering games — by default it uses O_DIRECT and varies offsets so the page cache can't cheat.

The flags that matter:

• -c 20 — fixed count, then exit. Good for scripting.
• -S 4G — work-set size. Defaults to 1 MiB, which entirely fits in cache. Bump it past your RAM if you want honest numbers.
• -s 64k — request size. Pair with realistic values for your workload (Postgres is 8K, most filesystems prefer 4K, video editors hit 1M+).
• -L — sequential, not random. Pair with -s 1M for honest bulk-throughput numbers that still beat dd.
• -W — write test. Be careful; it writes to a temp file in the target directory.
• -D — direct I/O (default on Linux, but explicit on macOS where you need it).
• -A — async I/O. Reveals how much your storage benefits from queue depth.

The trick most people miss: compare cached vs. uncached on the same device.

$ ioping -c 10 -C /data       # -C uses page cache, shows RAM speed
$ ioping -c 10 /data          # default O_DIRECT, shows real disk

When the first reports 2 µs and the second reports 8 ms, you've just diagnosed why your "fast" NVMe-backed service is bottlenecked: someone's working set blew past the cache.

Latency distribution, not just averages:

$ ioping -c 1000 -p 100 -P 1000 /var/lib/mysql
# -p 100 prints a summary every 100 requests
# -P 1000 reports requests-per-second instead of intervals

The mdev (mean deviation) field is the one that actually predicts user complaints. A drive averaging 200 µs with mdev 800 µs has p99 latencies that will ruin somebody's afternoon — and dd would have shown you a cheerful "450 MB/s" and called it a day.

Run it against /dev/sda directly (with care, read-only) to bypass the filesystem entirely. Run it against an NFS mount to find out which of your network or your server is the bottleneck. Run it in a tight loop during a backup window to watch latency degrade in real time. It's the tool you should have been reaching for the entire time.