Linux 7.4 stops XFS from bounce-buffering every checksummed direct read, a copy the kernel almost never needed
Christian Brauner's IOmap pull reads into the user buffer first and allocates a bounce buffer only when a checksum fails; no benchmark numbers have been published yet.
XFS bounce buffers every direct read on a device that requires stable pages for checksumming.
Comprehensive take
Axion take: a small structural fix that removes a copy from a hot path. We will believe the size of the win when someone publishes numbers; until then it is a sound design change with no measured payoff.
Use cases
Direct I/O on integrity-protected NVMe
Database and analytics hosts reading with direct I/O from devices that need stable pages for checksumming are the path this change touches.
Kernel and storage developers
Integrity verification moving from iomap into the filesystem is a design shift other filesystems using iomap may care about.
Who should wait
Anyone on a production kernel: this lands in Linux 7.4, still in development, and no performance figures exist yet.
Specs
| Change | Lazy bounce buffering for checksummed reads in XFS source |
|---|---|
| Merged via | VFS IOmap pull request, Linux 7.4 merge window source |
| Old I/O size effect | 1 MB minus 4k unaligned I/Os with 4k pages source |
| Published benchmarks | None in the patch series source |
Insights
- The old path bounce-buffered every direct read on devices needing stable pages, though the copy was almost never needed.
- The new path reads into the user buffer first and only allocates a bounce buffer on a checksum failure.
- No performance or CPU/DRAM savings figures were published with the series.
Linux 7.4 will stop making XFS copy data it almost never needs to copy. In the VFS IOmap pull request merged during the 7.4 merge window, Christian Brauner describes the old behaviour plainly: on a device that requires stable pages for checksumming, XFS bounce-buffered every direct read. The new code, per Phoronix's summary of the pull request, reads straight into the user buffer first and allocates a bounce buffer only if a checksum check fails, then reads again.
Why a bounce buffer was costing anything
A bounce buffer is a staging area: the kernel reads into it, verifies the data, then copies it to where the application asked for it. Brauner's description says the copies were "almost never needed" and burned DRAM bandwidth and CPU time on every direct read. He also notes a second cost: because the bounce buffer was a bio_vec, it produced smaller, unaligned I/Os, "1 MB minus 4k" with 4k pages, instead of clean large requests.
The fix inverts the common case. Checksum failures are rare, so the expensive path (allocate, re-read) now runs only on failure, and the normal path touches the data once. To make that possible, integrity verification moved out of iomap and into the filesystem, which lets XFS handle a failed check itself.
What we do not know yet
The patch series, as Phoronix reports, includes no numbers for the performance or CPU and DRAM savings. So any claim of a specific percentage gain would be invented, and we are not making one. What the change does establish is the direction of the saving: fewer memory copies and larger, aligned reads on checksummed block devices that need stable pages. Expect real measurements once 7.4 release candidates are available to benchmark on NVMe hardware with protection information enabled.
Who should care
Anyone running XFS on storage that enforces data integrity at the device level, especially database and analytics hosts doing direct I/O, is the audience. Desktop users reading files through the page cache are not affected by this particular path. Because the work lands in 7.4, which is still in development, nothing changes for production kernels today.
Axion take
This is the kind of fix that does not make a benchmark headline but compounds: removing a copy from a hot path frees memory bandwidth for everything else on the box. The gap is evidence. We would like to see a before-and-after on a fast NVMe array before calling it a win, and we will cover the numbers when they appear.