Storage performance benchmarking often focuses heavily on sequential throughput metrics—such as megabytes or gigabytes transferred per second. While sequential transfer speed is valuable for large file copies and video rendering, day-to-day server responsiveness and database transaction speeds depend far more critically on storage I/O latency. When NVMe SSDs, SATA drives, or network-attached NFS/iSCSI shares experience latency spikes, operating system commands hang and database queries queue up, even if raw bandwidth utilisation appears low.
Traditional benchmarking tools like fio and dd are exceptional for stress testing, but they can be destructive or complex to configure for rapid ad-hoc diagnostics. The ioping utility solves this challenge by operating similarly to the classic network ping command, but measuring disk request latency instead of ICMP network packets. This guide explains how to install and use ioping in the Linux terminal to measure real-time storage latency across physical drives, directories, and partitions.
What is ioping and Why is Latency Critical?
The ioping utility generates real-time I/O requests against a target file, directory, or raw block device and measures the exact duration the kernel storage subsystem takes to complete the round trip. By issuing small I/O operations (typically 4 KiB by default), it accurately simulates real-world transaction latency without flooding the drive with massive destructive writes.
Storage latency is typically quantified across three key benchmarks:
| Storage Media Type | Typical Random I/O Latency | Performance Implication |
|---|---|---|
| Enterprise NVMe SSD (PCIe 4.0 / 5.0) | 20 µs – 100 µs (microseconds) | Near-instantaneous database lookups and low I/O wait |
| Standard SATA SSD | 150 µs – 500 µs (microseconds) | Fast general-purpose hosting and application serving |
| Spinning Mechanical HDD (7200 RPM) | 8 ms – 15 ms (milliseconds) | High seek latency; prone to head thrashing under concurrent load |
| Network Storage (NFS, SMB, Ceph, iSCSI) | 1 ms – 25 ms (milliseconds) | Subject to network jitter, switch queuing, and storage controller latency |
Installing ioping Across Linux Distributions
The ioping package is available in the official package repositories of almost all major Linux distributions:
On Ubuntu, Debian, and Linux Mint:
sudo apt update
sudo apt install ioping -yOn RHEL, CentOS, Rocky Linux, and Fedora:
sudo dnf install epel-release -y
sudo dnf install ioping -yOn Arch Linux and Manjaro:
sudo pacman -S iopingRunning Basic Latency Tests Against a Directory
The simplest way to inspect disk responsiveness is to point ioping at a working directory on your target filesystem. When executed against a directory, ioping creates a temporary working file and performs read requests against it:
ioping .The terminal begins outputting continuous latency pings once every second:
4 KiB <<< . (ext4 /dev/nvme0n1p2): request=1 time=68.4 us
4 KiB <<< . (ext4 /dev/nvme0n1p2): request=2 time=71.2 us
4 KiB <<< . (ext4 /dev/nvme0n1p2): request=3 time=66.9 us
4 KiB <<< . (ext4 /dev/nvme0n1p2): request=4 time=73.1 usPress Ctrl + C to terminate the live test. Upon stopping, ioping summarises your minimum, average, maximum, and standard deviation latency metrics:
--- . (ext4 /dev/nvme0n1p2) ioping statistics ---
4 requests completed in 3.00 s, 16 KiB read, 1 iops, 5.3 KiB/s
generated 4 requests in 3.00 s, 16 KiB, 1 iops, 5.3 KiB/s
min/avg/max/mdev = 66.9 us / 69.9 us / 73.1 us / 2.3 usTesting Raw Storage Devices Directly
To bypass filesystem overhead, block caching layers, and journal delays, you can target raw disk block devices (such as /dev/sda or /dev/nvme0n1). This requires root privileges:
sudo ioping -c 10 /dev/nvme0n1The -c 10 flag instructs ioping to issue exactly 10 requests and automatically print the summary statistics without waiting for manual cancellation.
Benchmarking Sequential vs Random Seek Latency
Real-world workloads alternate between sequential reads (like streaming log files or backups) and random access (like relational database indexing). You can configure ioping to evaluate both profiles.
1. Testing Sequential Speed and Latency:
To measure sequential read latency across your drive, use the -R flag:
sudo ioping -R -c 10 /dev/sda2. Testing Pure Random Seek Latency:
To test random read seeks across the entire physical disk boundary, execute:
sudo ioping -c 20 -s 4k -D /dev/sdaThe -D switch enables direct I/O (O_DIRECT), which strictly instructs the Linux kernel to bypass the page cache entirely. This guarantees that every request hits physical NAND flash or magnetic platters rather than returning an inflated reading from RAM.
Auditing Cloud and Virtualised Storage Latency
When running Linux virtual machines on cloud platforms like AWS EC2, Google Cloud Platform, or Microsoft Azure, EBS or persistent disk throttling is a common source of application slowdowns. Running ioping during high-traffic periods helps identify whether slow database responses stem from compute bottlenecks or storage IOPS starvation.
If average latency jumps from 200 microseconds to upwards of 50 milliseconds while top shows elevated %wa (I/O wait), your virtual disk has likely exhausted its burst IOPS budget.
Using ioping provides Linux administrators with a lightweight, non-invasive method for validating disk response times, tuning database configurations, and isolating hardware latency issues in seconds.