]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
xfs: flush dirty pagecache over hole in zoned mode zero range
authorBrian Foster <bfoster@redhat.com>
Wed, 11 Mar 2026 16:24:56 +0000 (12:24 -0400)
committerCarlos Maiolino <cem@kernel.org>
Mon, 23 Mar 2026 10:07:59 +0000 (11:07 +0100)
commit2f46c239fce617ac26cc40d9520b1c0cf05cd34f
tree3376ed3a0a0a5cbbd2ea125c8cf78fd0a4794455
parent92e9dff9ca5026805798b13b967760f8058794e8
xfs: flush dirty pagecache over hole in zoned mode zero range

For zoned filesystems a window exists between the first write to a
sparse range (i.e. data fork hole) and writeback completion where we
might spuriously observe holes in both the COW and data forks. This
occurs because a buffered write populates the COW fork with
delalloc, writeback submission removes the COW fork delalloc blocks
and unlocks the inode, and then writeback completion remaps the
physically allocated blocks into the data fork. If a zero range
operation does a lookup during this window where both forks show a
hole, it incorrectly reports a hole mapping for a range that
contains data.

This currently works because iomap checks for dirty pagecache over
holes and unwritten mappings. If found, it flushes and retries the
lookup. We plan to remove the hole flush logic from iomap, however,
so lift the flush into xfs_zoned_buffered_write_iomap_begin() to
preserve behavior and document the purpose for it. Zoned XFS
filesystems don't support unwritten extents, so if zoned mode can
come up with a way to close this transient hole window in the
future, this flush can likely be removed.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
fs/xfs/xfs_iomap.c