# ioping: disk latency in the shape of ping

> ioping is a small C tool that reports disk I/O latency live, in the same request-by-request form ping uses for networks, with modes for seek rate and sequential throughput. It is a single source file with a cross platform makefile, a static build target and a multi-stage container recipe, and its last tagged release is from 2022.

**koct9i/ioping** — simple disk I/0 latency measuring tool

- Repository: https://github.com/koct9i/ioping
- Stars: 985 · Forks: 77
- Language: C
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/koct9i-ioping

## The ping analogy, taken literally

ioping is a tool to monitor I/O latency in real time, and the readme states its design in one sentence: it shows disk latency in the same way as ping shows network latency. The analogy is not decorative. A ping run is a sequence of timestamped probes, and an ioping run is a sequence of timestamped requests against a file or a device, printed one line at a time as they complete. Run against a directory with no arguments, it uses the current directory and the default values, and it keeps going until you interrupt it:

```bash
$ ioping .
4096 bytes from . (ext4 /dev/sda3): request=1 time=0.2 ms
4096 bytes from . (ext4 /dev/sda3): request=2 time=0.2 ms
4096 bytes from . (ext4 /dev/sda3): request=3 time=0.3 ms
4096 bytes from . (ext4 /dev/sda3): request=4 time=12.7 ms
4096 bytes from . (ext4 /dev/sda3): request=5 time=0.3 ms
^C
--- . (ext4 /dev/sda3) ioping statistics ---
5 requests completed in 4794.0 ms, 364 iops, 1.4 MiB/s
min/avg/max/mdev = 0.2/2.8/12.7/5.0 ms
```

The person this tool is for is an administrator staring at a slow machine. The output tells you not just that a disk is slow but that it is fast most of the time and occasionally terrible, which is the shape of a storage problem that an average-only number hides. The project was migrated from a code.google.com address, and patches, issues and questions go to the issue tracker on GitHub. The authors are Konstantin Khlebnikov and Kir Kolyshkin, and the licence is GPLv3 or later.

## Three modes: latency, seek rate and sequential speed

The default mode measures request latency, which is the closest thing to what a ping measures. Two flags turn it into a throughput tool. The -R flag measures the disk seek rate, reported as iops on average:

```bash
$ ioping -R /dev/sda

--- /dev/sda (device 465.8 GiB) ioping statistics ---
186 requests completed in 3004.6 ms, 62 iops, 0.2 MiB/s
min/avg/max/mdev = 6.4/16.0/26.8/4.7 ms
```

Adding L, as in -RL, measures sequential speed in MiB per second, and the same statistics block then shows a much higher throughput figure with a different latency profile:

```bash
$ ioping -RL /dev/sda

--- /dev/sda (device 465.8 GiB) ioping statistics ---
837 requests completed in 3004.1 ms, 292 iops, 72.9 MiB/s
min/avg/max/mdev = 2.0/3.4/28.9/2.0 ms
```

The distinction is the one that matters when you are diagnosing a slow workload. A workload that reads many small files cares about the seek rate, and a workload that streams cares about sequential speed, and a database that mixes both cares about the latency tail. Running the three modes against the same device before and after a change is a small amount of work that answers a lot of questions.

## The summary line is where the diagnosis happens

Each run ends with a statistics block that looks like ping's own summary, and the four numbers in the last line are min, avg, max and mdev, the standard deviation of the measurements. The examples in the readme are a good illustration of how to read them. The default run against a directory shows 0.2/2.8/12.7/5.0 ms, so the average is under three milliseconds, the worst request was 12.7, and the standard deviation of 5.0 is large relative to the average, which is what a device that is idle and then occasionally stalls looks like. The sequential run on the raw device shows 2.0/3.4/28.9/2.0 ms with 72.9 MiB/s, so the transfer rate is high and the latency floor is low. A large mdev next to a small average is the signature of an overloaded device queueing requests, and a uniformly high average points at the device itself rather than at contention. The tool also reports the filesystem and the backing device in the header line, which matters because a directory on a different mount than you expected will explain a lot.

## Packaging covers most of the systems it supports

The supported operating systems are GNU/Linux, GNU/HURD, Windows, OS X, FreeBSD, DragonFlyBSD and OpenBSD, and the packaging lists are long enough that installing it is rarely the hard part. Debian, Ubuntu, Fedora, Arch Linux, ALT Linux, Gentoo, Nix, the FreeBSD ports collection and the OS X Homebrew formula all carry it, and each entry points at the relevant package tracker. That list is worth reading as a compatibility statement: the tool has been built on all of these, which is more than a single file of C usually manages across a BSD and a Linux and a Windows. The practical consequence for an operator is that you can put the same measurement on both sides of a comparison, on the workstation that feels slow and on the server that is supposed to be fast, and know you are running the same code. Windows is supported through the cross compilation support in the makefile, using the x86_64-w64-mingw32 target with the ucrt specification.

## One C file, and a makefile that checks its own version

The source is a single file, ioping.c, alongside a man page, a changelog, a spec file for RPM based distributions and the makefile. The build defaults are unremarkable and modern enough: C11 in GNU dialect, with -Wall, -Wextra and -pedantic, and the usual -g -O2 plus loop unrolling and tree vectorisation. Linking is against the math and realtime libraries. The interesting target is checkver, which runs before the binary is built and compares the version in the git tag with the version define inside ioping.c, failing the build with a version mismatch error if they disagree. That check is there because the makefile derives its version from git describe, with a dirty tree suffix, and the source carries its own number, so a release can never be tagged with a version that does not match the code. There is a static target, a strip target and a test target that runs several invocations of the freshly built binary against the working directory and a temporary file.

## The container build produces four flavours from one recipe

The Dockerfile is a multi-stage build that produces a static binary for four distributions and then copies the result into an image with nothing else in it. Each distribution gets its own builder stage: Alpine with make, gcc, musl-dev and linux-headers, Debian and Ubuntu with make, gcc and libc6-dev, and Fedora with make, gcc and glibc-static. Every builder stage runs the same make static command, and each is followed by a scratch stage that copies the resulting binary in, so the final image contains a single file and no shell, no package manager and no libc. The practical payoff is that the same measurement can be run inside a container on a host where installing a tool would be unwelcome, and the static build is what makes that possible. The trade-off is that the image is a bare executable with no diagnostic tools, so if you want to look around the system from inside it you would need to add them deliberately.

## A committed project whose last release is from 2022

The release history is short: v1.0 in December 2016, v1.2 in February 2020 and v1.3 in August 2022. The last push was on 2026-10-03, so the code is still being worked on, and the makefile's version scheme will stamp a development build from a dirty tree with an extra suffix. The gap between those two facts is the thing to understand before you rely on it. Most distributions ship a packaged release, and that package is likely to be v1.3 from 2022, while the repository may have moved on. For a measurement tool whose output format is stable and whose behaviour on a given device is what you care about, that is rarely a problem. It does mean two things worth checking: that the version you compare against is the version you mean, and that a bug fixed in the tree after 2022 is not silently missing from the copy you are using. The code is GPLv3 or later, and the issue tracker is where the patches and questions go.

## Conclusion

ioping is the right tool when a workload feels slow and you need to know whether the storage is the bottleneck, because it shows the same latency pattern ping shows for a network and it is trivial to run on a machine that is already misbehaving. It is the wrong tool for a throughput benchmark of a whole filesystem, for measuring network latency, or for a system that does not let you run a foreground process against a raw device. Before you trust the numbers, note that the last push was on 2026-10-03 while the last release tag is v1.3 from 2022-08-24, so check which version your distribution ships and prefer the same tool on both sides of a comparison.

## FAQ

### What is ioping?

It is a small C tool that monitors disk I/O latency in real time and shows it in the same request-by-request way ping shows network latency, with a statistics summary of min, avg, max and mdev.

### Which operating systems does ioping support?

GNU/Linux, GNU/HURD, Windows, OS X, FreeBSD, DragonFlyBSD and OpenBSD. It is packaged for Debian, Ubuntu, Fedora, Arch Linux, ALT Linux, Gentoo, Nix, the FreeBSD ports and Homebrew.

### How do I measure disk seek rate and sequential speed with ioping?

Use ioping -R /dev/sda for the seek rate in iops, and ioping -RL /dev/sda for sequential speed in MiB per second. The default mode with no flags measures request latency against a path such as the current directory.

### How do I build ioping from source?

Run make in the repository, which builds the single ioping.c source file, or make static for a statically linked binary. The build runs a version check first that compares the git tag with the version in the source, and a test target runs several invocations of the built binary.

## Sources

- [Issues](https://github.com/koct9i/ioping/issues)
- [koct9i/ioping on GitHub](https://github.com/koct9i/ioping)
- [License: GPL-3.0](https://github.com/koct9i/ioping/blob/master/LICENSE)
- [README](https://github.com/koct9i/ioping/blob/master/README.md)
- [Releases](https://github.com/koct9i/ioping/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/koct9i-ioping