From fsync to Block I/O: Tracing Storage with eBPF
Observability stacks have gotten good at CPU, memory, and network — but storage is still where the picture goes dark. When a workload stalls on I/O, device-level tools like iostat or blktrace tell you the disk was busy; they don't tell you which service caused it, or where in the stack the latency actually accrued: a slow fsync, writeback pressure in the page cache, a filesystem journal commit, or a saturated block queue.
This talk follows a single write from the syscall boundary down to the block layer, using eBPF to instrument each handoff — VFS, the filesystem, the page cache, and block I/O submission and completion — without patching applications or running a custom kernel. We'll look at which attach points (tracepoints, fentry/fexit, kprobes) give honest per-layer latency, how to keep the measurement overhead from biasing the result, and how to attribute the latency back to the responsible cgroup or systemd service instead of an aggregate line on a dashboard. Examples range from fsync-heavy database commits to large sequential writes that look fine at the device level but stall well above it.
Attendees will leave with a concrete method for turning storage from a black box into a traceable path — and an honest sense of where eBPF helps, and where it still can't see.
Follow a single write from syscall to block layer with eBPF, measuring honest per-layer latency at each handoff and attributing storage stalls to the service that caused them.
Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/