Memory ECC and a drive’s internal error correction protect data while it resides in those components. They do not cover every DMA, cable, controller, driver, kernel buffer, and application copy between them. End-to-end data protection carries protection information (PI) beside each data block so several layers can verify a checksum, reference tag, and application tag.
Enterprise SCSI and NVMe devices have supported this metadata for more than a decade. Linux block integrity can pass PI in a separate buffer, yet the end-to-end path remained incomplete. Userspace lacked a read/write interface for data plus PI. The block layer rejected valid devices with unfamiliar PI placement. Filesystems neither created nor verified PI according to file semantics.
The work closes those plumbing gaps and proposes FS-PI, where a filesystem owns checksum policy while a capable device transports and verifies metadata. XFS gains data checksumming for the first time in this design. BTRFS replaces its separate checksum tree for data blocks with PI stored alongside device data, reducing recursive copy-on-write metadata updates.
A second buffer must follow every I/O lifecycle
The new io_uring interface lets an application submit or receive an integrity metadata buffer with ordinary data. The kernel validates length and layout, pins or maps both buffers, associates them with one request, and returns errors through the same completion. This allows databases, storage services, or test tools to participate without inventing an ioctl-only data path.
Flexible PI placement removes an assumption that metadata has one fixed offset. Real devices can reserve a larger metadata area and place the eight-byte tuple within it. The block layer must generate and verify at the configured location while preserving other device metadata. Supporting the layout is necessary for device compatibility; it does not change the checksum strength.
FS-PI adds an integrity flag to iomap, the common mapping layer used by XFS and other filesystems. Direct writes allocate PI and generate tuples before submitting the bio. Direct reads verify before completion reaches the application. Buffered reads attach PI while constructing folio I/O and verify before data becomes visible in the page cache. Buffered writes generate metadata when dirty pages are written back.
XFS and BTRFS start from opposite baselines
XFS protects its own metadata but historically does not checksum file data. FS-PI gives it CRC32C data checksums on Type-0 PI devices and covers buffered and direct I/O. The filesystem surfaces a detected mismatch to the caller using its I/O-error path. XFS has no redundant data copy to repair from, so detection does not imply recovery.
BTRFS already checksums data in a dedicated tree. Updating that tree performs extra reads and copy-on-write writes to checksum, extent, and filesystem trees. Type-0 PI reserves metadata without imposing the device’s standard guard algorithm, allowing BTRFS to store its own checksum value in the PI buffer. FS-PI removes the data checksum tree path while leaving metadata integrity and data redundancy behavior intact.
Thus, the two evaluations answer different questions. XFS measures the cost of adding a guarantee it did not have. BTRFS measures whether placing an existing guarantee with the block removes metadata work. Reporting only the BTRFS speedup would falsely suggest that checksumming is faster than no checksumming.
FS-PI also detects corruption during writes because the device checks data and PI on receipt. A software checksum tree usually discovers media or path corruption when data is read later. The earlier detection boundary is useful, but it depends on the device actually verifying tuples and on trust in its firmware.
BTRFS removes a recursive metadata path
The evaluation compared ordinary BTRFS checksum-tree operation with FS-PI. Random-write experiments issued four jobs, each writing 10GiB with 4KiB blocks and queue depth 128. Direct random writes fell from 813.66GiB of host writes to 391.14GiB, approximately 52%. Filesystem write amplification fell from 3.39 to 1.62.
Buffered random writes fell from 835.46GiB to 666.9GiB, about 20%, and filesystem amplification moved from 3.48 to 2.78. The smaller improvement reflects page-cache aggregation and different tree-update behavior. Read operations caused by writes dropped about 53% for direct I/O and 58% for buffered I/O.
At the device, direct random-write NAND traffic fell approximately 52%. With issue rate held equal, idle CPU increased from about 12% to 70%, corresponding to a 58-percentage-point reduction in utilized CPU under the reported comparison. Across the paper’s summary, BTRFS performance improved 26% and estimated SSD lifetime improved 23%.
The lifetime value derives from device-writes-per-day reduction under the tested workload and endurance model. It is not a warranty extension for arbitrary drives. Wear leveling, spare area, workload locality, data retention, and the PI metadata size all affect real lifetime.
XFS pays according to path and request shape
Adding FS-PI to XFS introduces generation and verification that its baseline lacks. Direct random writes cost about 4%, while direct sequential writes were around 2%. Buffered random and sequential reads added roughly 1% to 6%. Buffered random writes added about 1% to 2%, but buffered sequential writes reached approximately 20% overhead in the reported microbenchmarks.
Filebench applications amortized much of the tuple work and produced performance close to baseline XFS. The difference between microbenchmarks and applications matters. Small queue depth can expose per-request latency, while concurrency and other filesystem work hide it. A sequential buffered write can concentrate checksum generation in writeback and become CPU-limited.
An operator adding integrity should evaluate the actual read/write mix, block size, buffering, queue depth, and CPU budget. The correct comparison is XFS without data checksums against XFS with a new guarantee, not against BTRFS’s optimized removal of an old tree.
Protection metadata is not recovery or authenticity
PI detects accidental corruption and misdirected I/O using checksums and tags. It is not a cryptographic MAC. A malicious component that can modify data and recompute PI can evade it. Encryption without authentication also does not replace PI; the threat models and error locations differ.
Neither filesystem implementation in the paper protects filesystem metadata through FS-PI. Existing XFS and BTRFS metadata mechanisms remain responsible. XFS cannot reconstruct corrupted user data because it has no redundant copy. BTRFS may use duplication or RAID profiles to repair, but recovery policy sits above the mismatch signal.
Reference tags can detect a block delivered to the wrong logical address, while application tags can carry upper-layer context. Virtualization, device mapper, RAID, and multipath layers must transform or preserve those tags consistently. A layer that splits, merges, remaps, or clones bios can silently break end-to-end meaning even if each local checksum passes.
The io_uring API introduces lifetime and security questions for user-supplied metadata. The kernel must reject inconsistent buffer lengths and prevent one request’s PI from being reused with another’s data. Applications need a versioned description of tuple type, interval, placement, and seed so data can be recovered after software updates.
Deployment begins with a corruption matrix
A qualification plan should inject bit flips and misdirected blocks at the application buffer, page cache, bio data, PI buffer, DMA path, controller, and media. Each injection should have an expected detector, error code, log, retry policy, and recovery action. Passing a clean throughput benchmark proves none of these paths.
Telemetry should count PI generation, verification, mismatches by guard/reference/application tag, unsupported layouts, fallback I/O, and repairs. Silent fallback to an unprotected path is more dangerous than explicit failure. Mount and device discovery should state whether every active path supports the requested profile.
Mixed fleets need a policy for devices without PI. Software checksums can preserve detection but not the same write-path verification, and switching BTRFS between checksum-tree and FS-PI formats affects portability. Backup, scrub, send/receive, snapshots, reflinks, and device replacement must be tested with both representations.
Upstream status is also part of risk. The work upstreamed the io_uring and flexible-placement foundations, while FS-PI filesystem trees are research implementations the authors intend to bring to the kernel community. Product planning should distinguish accepted interfaces from out-of-tree filesystem code and budget for format and API changes.
Integrity has a different price in each filesystem
The paper demonstrates one shared mechanism with opposite performance meaning. For BTRFS, device PI replaces a costly checksum tree and cuts device writes 52%. For XFS, the same path adds data integrity with small to occasionally material overhead. Both are valid outcomes because the baseline guarantee differs.
The procurement question is which corruption locations need coverage and what recovery follows detection. A PI-capable drive, kernel plumbing, filesystem policy, and application interface must form one continuous contract. If any mapping layer strips metadata or changes tags incorrectly, the system returns to partial coverage.
FS-PI is compelling where BTRFS write amplification limits endurance or XFS workloads require data checksums and can accept measured overhead. Its broader lesson is that hardware capability remains unused until software expresses semantics at the right layer. End-to-end integrity is not a checkbox on the SSD; it is a property of every handoff between the application and media.
Source and copyright notice
This article is an editorial analysis by Silicon & Systems. It restates the interfaces, filesystem designs, measurements, and limitations in our own words. No source sentence, table, or figure is reproduced; the figure was created for this article. The paper is available from the USENIX FAST 2026 presentation page. Copyright remains with the authors, 2026.