Ext4 buffered I/O shifts from buffer_head to iomap

Zhang Yi of Huawei has posted version 6 of a large series that converts ext4's buffered I/O path for regular files from the classic buffer_head layer to the kernel's iomap framework.

Buffer_head has long tied page-cache work to fixed-size block buffers. iomap is the shared interface already used across much of the Linux filesystem stack for mapping file ranges into the page cache and writeback. Putting ext4 on that path aligns it with XFS and other modern filesystems, reduces duplicated logic, and is a step toward cleaner large-folio and writeback behavior.

The work is not a straight swap. data=ordered journaling clashes with iomap writeback lock ordering and can deadlock when a journal commit waits on a folio that iomap already holds while starting a new transaction. The iomap path therefore does not rely on data=ordered for buffered I/O. That removes an implicit guarantee around the zeroed partial block at an unaligned end of file, so the series adds explicit state to keep that zeroed tail ordered with later advances of the on-disk size. Without it, a crash after an extending write could expose stale data past the old end of file. Collapse-range, insert-range, punch, and related operations flush or wait on that pending range before moving the on-disk size.

Online defragmentation still depends on buffer_head and data=ordered details, so it is rejected for inodes that use the new path until separate support lands. Inline data is also out of scope for now.

Testing with xfstests (auto, fast_commit, and 64k configurations) showed no new failures beyond a known occasional generic/127 issue in MM large-folio split logic. FIO results on a RAM-backed virtual block device were unchanged from v5. Jan Kara and Ojaswin Mujoo have reviewed substantial parts of the series.