Ext4 buffered I/O moves to iomap in large opt-in series

Ext4 is gaining an opt-in path that runs regular-file buffered I/O through iomap instead of the long-standing buffer_head stack, a structural shift meant to modernize the filesystem’s page-cache and writeback handling.

Zhang Yi of Huawei posted v7 of the 31-patch series on the linux-kernel list. An earlier revision is already in the ext4 development tree. The work reimplements buffered read, write, writeback, mmap, and partial-block zeroing on iomap, and it drops data=ordered semantics for inodes that take the new path.

That drop forced extra care around unaligned file extension. Without ordered mode, a zeroed block that straddles the on-disk size can lag behind metadata updates and expose stale data after a crash. Following guidance from Jan Kara, the series tracks a disksize-grow-pending state: writeback of that zeroed EOF range is tagged and completed (or discarded) before i_disksize is allowed to advance, with waiters and flush points wired into fallocate, collapse/insert range, punch, truncate, and eviction.

The new path is not the default. Mount options buffered_iomap and nobuffered_iomap control it; a remount change applies only after an inode is re-read from disk. Inodes still fall back to buffer_head when inline data, fsverity, fscrypt, indirect addressing, or full data=journal mode is in play. Bigalloc and ordinary default features are supported. Online defragmentation is explicitly rejected for iomap inodes until it is rewritten for the new model.

xfstests under auto, fast_commit, and 64k configurations showed no new failures beyond a known MM large-folio split issue tracked separately. FIO numbers on a RAM-backed guest were reported as unchanged from an earlier revision. Enabling the path is therefore a deliberate choice for sites that want the modern I/O stack and can live without the still-unsupported features.