News › linux
By The Linux Camp News, October 12, 2026
The October 12 development-tree snapshot contains a new regular-file buffered-I/O path. It remains optional, disables online defragmentation for affected files, and has not been confirmed for a released kernel.
As of the October 12, 2026 source retrieval, EXT4's maintainer development branch contains Zhang Yi's iomap implementation for regular-file buffered I/O, including its opt-in mount option. This is a queued filesystem change, not confirmation of a released kernel feature. Phoronix anticipates submission during the Linux 7.4 merge window; the supplied records do not establish mainline inclusion. 3 1
The conversion replaces buffer_head-based handling with iomap, a Linux framework that maps positions within files to device blocks. It extends ext4_map_blocks() and supplies buffered reads, writes, writeback, memory-mapped access and partial-block zeroing. Phoronix attributes the efficiency rationale to lower buffer-head memory overhead and better integration with Linux folios. That explains the intended benefit of changing the underlying machinery, but does not isolate the cause of individual benchmark gains. 1 2
File growth also needs coordinated ordering. When the old end of file falls inside a block, the series coordinates zeroing that partial block with updating i_disksize. The queued changes defer this size update while growth I/O is pending and advance it on completion. The practical distinction is that submitting the growth I/O and completing it are separate events; the size update must respect that separation. 2 3
Zhang's benchmark assessment is a trade-off rather than a blanket speedup: large writes improved significantly, small synchronous and non-cached writes showed regressions, and reads showed no significant overall difference. The operational inference is to compare the path against the application's actual write sizes and synchronization behavior, rather than treating a large-write gain as evidence that every EXT4 workload benefits. 2
On a kernel carrying the implementation, selecting buffered_iomap explicitly opts into the new path. Leaving it unset avoids adopting the conversion by default: feature coverage is incomplete. Check feature requirements as well as performance before testing adoption, particularly if online defragmentation is part of operations, because the queued code disables it for inodes using iomap buffered I/O. 1 3
The performance evidence comes from the developer's FIO tests in a four-core VM using a 150GB RAM-backed block device. The v6 cover letter reused v5 measurements because the author considered the intervening changes insignificant. These are therefore not fresh measurements of the queued branch, nor evidence of equivalent gains on physical SSDs or HDDs. Production-storage performance remains an open testing question. 2