[PATCH v3 0/8] iomap, xfs: improve zero range flushing and lookup

[PATCH v3 0/8] iomap, xfs: improve zero range flushing and lookup

[Brian Foster]

Hi all,

Here's v3 of the patches to lift and replace the hole mapping pagecache
flush logic from iomap into XFS and clean it up. The major changes from
v2 are the addition of patches 1, 2 and 8.

Christoph discovered a regression with zero range in zoned mode on v2 of
the series. The problem is that the zoned mode iomap_begin() relied on
the hole mapping flush to handle the case where writes are pending but
blocks have not yet been mapped into the data fork for the first time.
Patches 1-2 lift the flush into the begin handler, document the purpose,
and clean up the logic a bit. They are inserted at the beginning of the
series to avoid regression from removing the flush from iomap in patch
3, but ordering is not critical as zoned support is experimental.

Patch 8 changes the normal buffered write iomap_begin() handler to no
longer report a hole in the situation where we have dirty pagecache
backed by COW fork blocks and a data fork hole. Since the main
differentiator between representing this case as a hole or data mapping
is pagecache, the folio lookup provides a straightforward way to
distinguish between the two.

Otherwise v3 includes some miscellaneous updates to logic, comments,
whitespace, etc. based on feedback to v2.

Brian

v3:
- Inserted new patches 1-2 to fix up zoned mode zeroing.
- Appended patch 8 to correctly report COW mappings backed by data fork
  holes.
- Various minor fixups to logic, whitespace, comments.
v2: https://lore.kernel.org/linux-fsdevel/20260129155028.141110-1-bfoster@redhat.com/
- Patch 1 from v1 merged separately.
- Fixed up iomap_fill_dirty_folios() call in patch 5.
v1: https://lore.kernel.org/linux-fsdevel/20251016190303.53881-1-bfoster@redhat.com/

Brian Foster (8):
  xfs: fix iomap hole map reporting for zoned zero range
  xfs: flush dirty pagecache over hole in zoned mode zero range
  iomap, xfs: lift zero range hole mapping flush into xfs
  xfs: flush eof folio before insert range size update
  xfs: look up cow fork extent earlier for buffered iomap_begin
  xfs: only flush when COW fork blocks overlap data fork holes
  xfs: replace zero range flush with folio batch
  xfs: report cow mappings with dirty pagecache for iomap zero range

 fs/iomap/buffered-io.c |   6 +-
 fs/xfs/xfs_file.c      |  17 +++++
 fs/xfs/xfs_iomap.c     | 145 +++++++++++++++++++++++++++++++----------
 3 files changed, 129 insertions(+), 39 deletions(-)

-- 
2.52.0

[PATCH v3 1/8] xfs: fix iomap hole map reporting for zoned zero range

[Brian Foster]

The hole mapping logic for zero range in zoned mode is not quite
correct. It currently reports a hole whenever one exists in the data
fork. If the first write to a sparse range has completed and not yet
written back, the blocks exist in the COW fork as delalloc until
writeback completes, at which point they are allocated and mapped
into the data fork. If a zero range occurs on a range that has not
yet populated the data fork, we will incorrectly report it as a
hole.

Note that this currently functions correctly because we are bailed
out by the pagecache flush in iomap_zero_range(). If a hole or
unwritten mapping is reported with dirty pagecache, it assumes there
is pending data, flushes to induce any pending block
allocations/remaps, and retries the lookup. We want to remove this
hack from iomap, however, so update iomap_begin() to only report a
hole for zeroing when one exists in both forks.

Signed-off-by: Brian Foster <bfoster@redhat.com>
---
 fs/xfs/xfs_iomap.c | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index be86d43044df..8c3469d2c73e 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -1651,14 +1651,6 @@ xfs_zoned_buffered_write_iomap_begin(
 				&smap))
 			smap.br_startoff = end_fsb; /* fake hole until EOF */
 		if (smap.br_startoff > offset_fsb) {
-			/*
-			 * We never need to allocate blocks for zeroing a hole.
-			 */
-			if (flags & IOMAP_ZERO) {
-				xfs_hole_to_iomap(ip, iomap, offset_fsb,
-						smap.br_startoff);
-				goto out_unlock;
-			}
 			end_fsb = min(end_fsb, smap.br_startoff);
 		} else {
 			end_fsb = min(end_fsb,
@@ -1690,6 +1682,16 @@ xfs_zoned_buffered_write_iomap_begin(
 	count_fsb = min3(end_fsb - offset_fsb, XFS_MAX_BMBT_EXTLEN,
 			 XFS_B_TO_FSB(mp, 1024 * PAGE_SIZE));
 
+	/*
+	 * When zeroing, don't allocate blocks for holes as they are already
+	 * zeroes, but we need to ensure that no extents exist in both the data
+	 * and COW fork to ensure this really is a hole.
+	 */
+	if ((flags & IOMAP_ZERO) && srcmap->type == IOMAP_HOLE) {
+		xfs_hole_to_iomap(ip, iomap, offset_fsb, end_fsb);
+		goto out_unlock;
+	}
+
 	/*
 	 * The block reservation is supposed to cover all blocks that the
 	 * operation could possible write, but there is a nasty corner case
-- 
2.52.0

Re: [PATCH v3 1/8] xfs: fix iomap hole map reporting for zoned zero range

[Darrick J. Wong]

On Mon, Mar 09, 2026 at 09:44:59AM -0400, Brian Foster wrote:
> The hole mapping logic for zero range in zoned mode is not quite
> correct. It currently reports a hole whenever one exists in the data
> fork. If the first write to a sparse range has completed and not yet
> written back, the blocks exist in the COW fork as delalloc until
> writeback completes, at which point they are allocated and mapped
> into the data fork. If a zero range occurs on a range that has not
> yet populated the data fork, we will incorrectly report it as a
> hole.
> 
> Note that this currently functions correctly because we are bailed
> out by the pagecache flush in iomap_zero_range(). If a hole or
> unwritten mapping is reported with dirty pagecache, it assumes there
> is pending data, flushes to induce any pending block
> allocations/remaps, and retries the lookup. We want to remove this
> hack from iomap, however, so update iomap_begin() to only report a
> hole for zeroing when one exists in both forks.
> 
> Signed-off-by: Brian Foster <bfoster@redhat.com>
> ---
>  fs/xfs/xfs_iomap.c | 18 ++++++++++--------
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index be86d43044df..8c3469d2c73e 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -1651,14 +1651,6 @@ xfs_zoned_buffered_write_iomap_begin(
>  				&smap))
>  			smap.br_startoff = end_fsb; /* fake hole until EOF */
>  		if (smap.br_startoff > offset_fsb) {
> -			/*
> -			 * We never need to allocate blocks for zeroing a hole.
> -			 */
> -			if (flags & IOMAP_ZERO) {
> -				xfs_hole_to_iomap(ip, iomap, offset_fsb,
> -						smap.br_startoff);
> -				goto out_unlock;
> -			}
>  			end_fsb = min(end_fsb, smap.br_startoff);
>  		} else {
>  			end_fsb = min(end_fsb,
> @@ -1690,6 +1682,16 @@ xfs_zoned_buffered_write_iomap_begin(
>  	count_fsb = min3(end_fsb - offset_fsb, XFS_MAX_BMBT_EXTLEN,
>  			 XFS_B_TO_FSB(mp, 1024 * PAGE_SIZE));
>  
> +	/*
> +	 * When zeroing, don't allocate blocks for holes as they are already
> +	 * zeroes, but we need to ensure that no extents exist in both the data
> +	 * and COW fork to ensure this really is a hole.

But where is the cow fork check?  iomap_iter initializes srcmap to
IOMAP_HOLE, so if we end up here on an IOMAP_ZERO then we've scanned the
data fork and found no mapping.  But then we jump to out_unlock, which
means we don't actually look at ip->cowfp.

<confused>

--D

> +	 */
> +	if ((flags & IOMAP_ZERO) && srcmap->type == IOMAP_HOLE) {
> +		xfs_hole_to_iomap(ip, iomap, offset_fsb, end_fsb);
> +		goto out_unlock;
> +	}
> +
>  	/*
>  	 * The block reservation is supposed to cover all blocks that the
>  	 * operation could possible write, but there is a nasty corner case
> -- 
> 2.52.0
> 
> 

Re: [PATCH v3 1/8] xfs: fix iomap hole map reporting for zoned zero range

[Brian Foster]

On Mon, Mar 09, 2026 at 10:11:00AM -0700, Darrick J. Wong wrote:
> On Mon, Mar 09, 2026 at 09:44:59AM -0400, Brian Foster wrote:
> > The hole mapping logic for zero range in zoned mode is not quite
> > correct. It currently reports a hole whenever one exists in the data
> > fork. If the first write to a sparse range has completed and not yet
> > written back, the blocks exist in the COW fork as delalloc until
> > writeback completes, at which point they are allocated and mapped
> > into the data fork. If a zero range occurs on a range that has not
> > yet populated the data fork, we will incorrectly report it as a
> > hole.
> > 
> > Note that this currently functions correctly because we are bailed
> > out by the pagecache flush in iomap_zero_range(). If a hole or
> > unwritten mapping is reported with dirty pagecache, it assumes there
> > is pending data, flushes to induce any pending block
> > allocations/remaps, and retries the lookup. We want to remove this
> > hack from iomap, however, so update iomap_begin() to only report a
> > hole for zeroing when one exists in both forks.
> > 
> > Signed-off-by: Brian Foster <bfoster@redhat.com>
> > ---
> >  fs/xfs/xfs_iomap.c | 18 ++++++++++--------
> >  1 file changed, 10 insertions(+), 8 deletions(-)
> > 
> > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> > index be86d43044df..8c3469d2c73e 100644
> > --- a/fs/xfs/xfs_iomap.c
> > +++ b/fs/xfs/xfs_iomap.c
> > @@ -1651,14 +1651,6 @@ xfs_zoned_buffered_write_iomap_begin(
> >  				&smap))
> >  			smap.br_startoff = end_fsb; /* fake hole until EOF */
> >  		if (smap.br_startoff > offset_fsb) {
> > -			/*
> > -			 * We never need to allocate blocks for zeroing a hole.
> > -			 */
> > -			if (flags & IOMAP_ZERO) {
> > -				xfs_hole_to_iomap(ip, iomap, offset_fsb,
> > -						smap.br_startoff);
> > -				goto out_unlock;
> > -			}
> >  			end_fsb = min(end_fsb, smap.br_startoff);
> >  		} else {
> >  			end_fsb = min(end_fsb,
> > @@ -1690,6 +1682,16 @@ xfs_zoned_buffered_write_iomap_begin(
> >  	count_fsb = min3(end_fsb - offset_fsb, XFS_MAX_BMBT_EXTLEN,
> >  			 XFS_B_TO_FSB(mp, 1024 * PAGE_SIZE));
> >  
> > +	/*
> > +	 * When zeroing, don't allocate blocks for holes as they are already
> > +	 * zeroes, but we need to ensure that no extents exist in both the data
> > +	 * and COW fork to ensure this really is a hole.
> 
> But where is the cow fork check?  iomap_iter initializes srcmap to
> IOMAP_HOLE, so if we end up here on an IOMAP_ZERO then we've scanned the
> data fork and found no mapping.  But then we jump to out_unlock, which
> means we don't actually look at ip->cowfp.
> 

The COW fork is checked a few lines up from where this is added. If it
finds blocks it exits out, if not it falls into this codepath for
allocation into the fork (implying a hole).

Brian

> <confused>
> 
> --D
> 
> > +	 */
> > +	if ((flags & IOMAP_ZERO) && srcmap->type == IOMAP_HOLE) {
> > +		xfs_hole_to_iomap(ip, iomap, offset_fsb, end_fsb);
> > +		goto out_unlock;
> > +	}
> > +
> >  	/*
> >  	 * The block reservation is supposed to cover all blocks that the
> >  	 * operation could possible write, but there is a nasty corner case
> > -- 
> > 2.52.0
> > 
> > 
> 

Re: [PATCH v3 1/8] xfs: fix iomap hole map reporting for zoned zero range

[Darrick J. Wong]

On Mon, Mar 09, 2026 at 02:18:56PM -0400, Brian Foster wrote:
> On Mon, Mar 09, 2026 at 10:11:00AM -0700, Darrick J. Wong wrote:
> > On Mon, Mar 09, 2026 at 09:44:59AM -0400, Brian Foster wrote:
> > > The hole mapping logic for zero range in zoned mode is not quite
> > > correct. It currently reports a hole whenever one exists in the data
> > > fork. If the first write to a sparse range has completed and not yet
> > > written back, the blocks exist in the COW fork as delalloc until
> > > writeback completes, at which point they are allocated and mapped
> > > into the data fork. If a zero range occurs on a range that has not
> > > yet populated the data fork, we will incorrectly report it as a
> > > hole.
> > > 
> > > Note that this currently functions correctly because we are bailed
> > > out by the pagecache flush in iomap_zero_range(). If a hole or
> > > unwritten mapping is reported with dirty pagecache, it assumes there
> > > is pending data, flushes to induce any pending block
> > > allocations/remaps, and retries the lookup. We want to remove this
> > > hack from iomap, however, so update iomap_begin() to only report a
> > > hole for zeroing when one exists in both forks.
> > > 
> > > Signed-off-by: Brian Foster <bfoster@redhat.com>
> > > ---
> > >  fs/xfs/xfs_iomap.c | 18 ++++++++++--------
> > >  1 file changed, 10 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> > > index be86d43044df..8c3469d2c73e 100644
> > > --- a/fs/xfs/xfs_iomap.c
> > > +++ b/fs/xfs/xfs_iomap.c
> > > @@ -1651,14 +1651,6 @@ xfs_zoned_buffered_write_iomap_begin(
> > >  				&smap))
> > >  			smap.br_startoff = end_fsb; /* fake hole until EOF */
> > >  		if (smap.br_startoff > offset_fsb) {
> > > -			/*
> > > -			 * We never need to allocate blocks for zeroing a hole.
> > > -			 */
> > > -			if (flags & IOMAP_ZERO) {
> > > -				xfs_hole_to_iomap(ip, iomap, offset_fsb,
> > > -						smap.br_startoff);
> > > -				goto out_unlock;
> > > -			}
> > >  			end_fsb = min(end_fsb, smap.br_startoff);
> > >  		} else {
> > >  			end_fsb = min(end_fsb,
> > > @@ -1690,6 +1682,16 @@ xfs_zoned_buffered_write_iomap_begin(
> > >  	count_fsb = min3(end_fsb - offset_fsb, XFS_MAX_BMBT_EXTLEN,
> > >  			 XFS_B_TO_FSB(mp, 1024 * PAGE_SIZE));
> > >  
> > > +	/*
> > > +	 * When zeroing, don't allocate blocks for holes as they are already
> > > +	 * zeroes, but we need to ensure that no extents exist in both the data
> > > +	 * and COW fork to ensure this really is a hole.
> > 
> > But where is the cow fork check?  iomap_iter initializes srcmap to
> > IOMAP_HOLE, so if we end up here on an IOMAP_ZERO then we've scanned the
> > data fork and found no mapping.  But then we jump to out_unlock, which
> > means we don't actually look at ip->cowfp.
> > 
> 
> The COW fork is checked a few lines up from where this is added. If it
> finds blocks it exits out, if not it falls into this codepath for
> allocation into the fork (implying a hole).

Ah silly me falling off the end of the (diff) context window
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

--D

> 
> Brian
> 
> > <confused>
> > 
> > --D
> > 
> > > +	 */
> > > +	if ((flags & IOMAP_ZERO) && srcmap->type == IOMAP_HOLE) {
> > > +		xfs_hole_to_iomap(ip, iomap, offset_fsb, end_fsb);
> > > +		goto out_unlock;
> > > +	}
> > > +
> > >  	/*
> > >  	 * The block reservation is supposed to cover all blocks that the
> > >  	 * operation could possible write, but there is a nasty corner case
> > > -- 
> > > 2.52.0
> > > 
> > > 
> > 
> 
> 

Re: [PATCH v3 1/8] xfs: fix iomap hole map reporting for zoned zero range

[Christoph Hellwig]

On Mon, Mar 09, 2026 at 09:44:59AM -0400, Brian Foster wrote:
> The hole mapping logic for zero range in zoned mode is not quite
> correct. It currently reports a hole whenever one exists in the data
> fork. If the first write to a sparse range has completed and not yet
> written back, the blocks exist in the COW fork as delalloc until
> writeback completes, at which point they are allocated and mapped
> into the data fork. If a zero range occurs on a range that has not
> yet populated the data fork, we will incorrectly report it as a
> hole.
> 
> Note that this currently functions correctly because we are bailed
> out by the pagecache flush in iomap_zero_range(). If a hole or
> unwritten mapping is reported with dirty pagecache, it assumes there
> is pending data, flushes to induce any pending block
> allocations/remaps, and retries the lookup. We want to remove this
> hack from iomap, however, so update iomap_begin() to only report a
> hole for zeroing when one exists in both forks.
> 
> Signed-off-by: Brian Foster <bfoster@redhat.com>

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

[PATCH v3 2/8] xfs: flush dirty pagecache over hole in zoned mode zero range

[Brian Foster]

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>
---
 fs/xfs/xfs_iomap.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 8c3469d2c73e..0e323e4e304b 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -1590,6 +1590,7 @@ xfs_zoned_buffered_write_iomap_begin(
 {
 	struct iomap_iter	*iter =
 		container_of(iomap, struct iomap_iter, iomap);
+	struct address_space	*mapping = inode->i_mapping;
 	struct xfs_zone_alloc_ctx *ac = iter->private;
 	struct xfs_inode	*ip = XFS_I(inode);
 	struct xfs_mount	*mp = ip->i_mount;
@@ -1614,6 +1615,7 @@ xfs_zoned_buffered_write_iomap_begin(
 	if (error)
 		return error;
 
+restart:
 	error = xfs_ilock_for_iomap(ip, flags, &lockmode);
 	if (error)
 		return error;
@@ -1686,8 +1688,25 @@ xfs_zoned_buffered_write_iomap_begin(
 	 * When zeroing, don't allocate blocks for holes as they are already
 	 * zeroes, but we need to ensure that no extents exist in both the data
 	 * and COW fork to ensure this really is a hole.
+	 *
+	 * A window exists where we might observe a hole in both forks with
+	 * valid data in cache. Writeback removes the COW fork blocks on
+	 * submission but doesn't remap into the data fork until completion. If
+	 * the data fork was previously a hole, we'll fail to zero. Until we
+	 * find a way to avoid this transient state, check for dirty pagecache
+	 * and flush to wait on blocks to land in the data fork.
 	 */
 	if ((flags & IOMAP_ZERO) && srcmap->type == IOMAP_HOLE) {
+		if (filemap_range_needs_writeback(mapping, offset,
+						  offset + count - 1)) {
+			xfs_iunlock(ip, lockmode);
+			error = filemap_write_and_wait_range(mapping, offset,
+							    offset + count - 1);
+			if (error)
+				return error;
+			goto restart;
+		}
+
 		xfs_hole_to_iomap(ip, iomap, offset_fsb, end_fsb);
 		goto out_unlock;
 	}
-- 
2.52.0

Re: [PATCH v3 2/8] xfs: flush dirty pagecache over hole in zoned mode zero range

[Darrick J. Wong]

On Mon, Mar 09, 2026 at 09:45:00AM -0400, Brian Foster wrote:
> 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.

Why does the mapping disappear out of both data and cow forks between
writeback setup and completion?  IIRC it is because the writeback ioend
effectively owns the unwritten mapping.  We want another writer thread
to see the hole and reserve its own out-of-place write because the write
mapping that writeback's working on is immutable once the disk actually
writes it.  Right?

I wonder if we could stash a delalloc mapping in the cow fork with zero
indlen during writeback to signal "get a real zoned space reservation"?

> Signed-off-by: Brian Foster <bfoster@redhat.com>
> ---
>  fs/xfs/xfs_iomap.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index 8c3469d2c73e..0e323e4e304b 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -1590,6 +1590,7 @@ xfs_zoned_buffered_write_iomap_begin(
>  {
>  	struct iomap_iter	*iter =
>  		container_of(iomap, struct iomap_iter, iomap);
> +	struct address_space	*mapping = inode->i_mapping;
>  	struct xfs_zone_alloc_ctx *ac = iter->private;
>  	struct xfs_inode	*ip = XFS_I(inode);
>  	struct xfs_mount	*mp = ip->i_mount;
> @@ -1614,6 +1615,7 @@ xfs_zoned_buffered_write_iomap_begin(
>  	if (error)
>  		return error;
>  
> +restart:
>  	error = xfs_ilock_for_iomap(ip, flags, &lockmode);
>  	if (error)
>  		return error;
> @@ -1686,8 +1688,25 @@ xfs_zoned_buffered_write_iomap_begin(
>  	 * When zeroing, don't allocate blocks for holes as they are already
>  	 * zeroes, but we need to ensure that no extents exist in both the data
>  	 * and COW fork to ensure this really is a hole.
> +	 *
> +	 * A window exists where we might observe a hole in both forks with
> +	 * valid data in cache. Writeback removes the COW fork blocks on
> +	 * submission but doesn't remap into the data fork until completion. If
> +	 * the data fork was previously a hole, we'll fail to zero. Until we
> +	 * find a way to avoid this transient state, check for dirty pagecache
> +	 * and flush to wait on blocks to land in the data fork.
>  	 */
>  	if ((flags & IOMAP_ZERO) && srcmap->type == IOMAP_HOLE) {
> +		if (filemap_range_needs_writeback(mapping, offset,
> +						  offset + count - 1)) {
> +			xfs_iunlock(ip, lockmode);
> +			error = filemap_write_and_wait_range(mapping, offset,
> +							    offset + count - 1);

Two tab indents, please.

--D

> +			if (error)
> +				return error;
> +			goto restart;
> +		}
> +
>  		xfs_hole_to_iomap(ip, iomap, offset_fsb, end_fsb);
>  		goto out_unlock;
>  	}
> -- 
> 2.52.0
> 
> 

Re: [PATCH v3 2/8] xfs: flush dirty pagecache over hole in zoned mode zero range

[Brian Foster]

On Mon, Mar 09, 2026 at 10:22:19AM -0700, Darrick J. Wong wrote:
> On Mon, Mar 09, 2026 at 09:45:00AM -0400, Brian Foster wrote:
> > 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.
> 
> Why does the mapping disappear out of both data and cow forks between
> writeback setup and completion?  IIRC it is because the writeback ioend
> effectively owns the unwritten mapping.  We want another writer thread
> to see the hole and reserve its own out-of-place write because the write
> mapping that writeback's working on is immutable once the disk actually
> writes it.  Right?
> 

Not sure.. seems plausible, but probably a question for Christoph.

> I wonder if we could stash a delalloc mapping in the cow fork with zero
> indlen during writeback to signal "get a real zoned space reservation"?
> 

I was thinking something like transferring the delalloc to the data fork
when the latter has a hole just to signify that there is data in the
pipeline, but not something to solve for this series anyways..

> > Signed-off-by: Brian Foster <bfoster@redhat.com>
> > ---
> >  fs/xfs/xfs_iomap.c | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> > 
> > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> > index 8c3469d2c73e..0e323e4e304b 100644
> > --- a/fs/xfs/xfs_iomap.c
> > +++ b/fs/xfs/xfs_iomap.c
> > @@ -1590,6 +1590,7 @@ xfs_zoned_buffered_write_iomap_begin(
> >  {
> >  	struct iomap_iter	*iter =
> >  		container_of(iomap, struct iomap_iter, iomap);
> > +	struct address_space	*mapping = inode->i_mapping;
> >  	struct xfs_zone_alloc_ctx *ac = iter->private;
> >  	struct xfs_inode	*ip = XFS_I(inode);
> >  	struct xfs_mount	*mp = ip->i_mount;
> > @@ -1614,6 +1615,7 @@ xfs_zoned_buffered_write_iomap_begin(
> >  	if (error)
> >  		return error;
> >  
> > +restart:
> >  	error = xfs_ilock_for_iomap(ip, flags, &lockmode);
> >  	if (error)
> >  		return error;
> > @@ -1686,8 +1688,25 @@ xfs_zoned_buffered_write_iomap_begin(
> >  	 * When zeroing, don't allocate blocks for holes as they are already
> >  	 * zeroes, but we need to ensure that no extents exist in both the data
> >  	 * and COW fork to ensure this really is a hole.
> > +	 *
> > +	 * A window exists where we might observe a hole in both forks with
> > +	 * valid data in cache. Writeback removes the COW fork blocks on
> > +	 * submission but doesn't remap into the data fork until completion. If
> > +	 * the data fork was previously a hole, we'll fail to zero. Until we
> > +	 * find a way to avoid this transient state, check for dirty pagecache
> > +	 * and flush to wait on blocks to land in the data fork.
> >  	 */
> >  	if ((flags & IOMAP_ZERO) && srcmap->type == IOMAP_HOLE) {
> > +		if (filemap_range_needs_writeback(mapping, offset,
> > +						  offset + count - 1)) {
> > +			xfs_iunlock(ip, lockmode);
> > +			error = filemap_write_and_wait_range(mapping, offset,
> > +							    offset + count - 1);
> 
> Two tab indents, please.
> 

Sure.

Brian

> --D
> 
> > +			if (error)
> > +				return error;
> > +			goto restart;
> > +		}
> > +
> >  		xfs_hole_to_iomap(ip, iomap, offset_fsb, end_fsb);
> >  		goto out_unlock;
> >  	}
> > -- 
> > 2.52.0
> > 
> > 
> 

Re: [PATCH v3 2/8] xfs: flush dirty pagecache over hole in zoned mode zero range

[Christoph Hellwig]

On Mon, Mar 09, 2026 at 10:22:19AM -0700, Darrick J. Wong wrote:
> Why does the mapping disappear out of both data and cow forks between
> writeback setup and completion?  IIRC it is because the writeback ioend
> effectively owns the unwritten mapping.  We want another writer thread
> to see the hole and reserve its own out-of-place write because the write
> mapping that writeback's working on is immutable once the disk actually
> writes it.  Right?

Mostly because we don't have good code to turn a COW fork delalloc
mapping into a data fork written one.  Unwritten extents do not actually
exist for zoned RT forks.

> I wonder if we could stash a delalloc mapping in the cow fork with zero
> indlen during writeback to signal "get a real zoned space reservation"?

What would that help with?

Re: [PATCH v3 2/8] xfs: flush dirty pagecache over hole in zoned mode zero range

[Darrick J. Wong]

On Mon, Mar 09, 2026 at 11:47:23PM -0700, Christoph Hellwig wrote:
> On Mon, Mar 09, 2026 at 10:22:19AM -0700, Darrick J. Wong wrote:
> > Why does the mapping disappear out of both data and cow forks between
> > writeback setup and completion?  IIRC it is because the writeback ioend
> > effectively owns the unwritten mapping.  We want another writer thread
> > to see the hole and reserve its own out-of-place write because the write
> > mapping that writeback's working on is immutable once the disk actually
> > writes it.  Right?
> 
> Mostly because we don't have good code to turn a COW fork delalloc
> mapping into a data fork written one.  Unwritten extents do not actually
> exist for zoned RT forks.
> 
> > I wonder if we could stash a delalloc mapping in the cow fork with zero
> > indlen during writeback to signal "get a real zoned space reservation"?
> 
> What would that help with?

Faking out iomap zeroing, and probably not much else.

--D

Re: [PATCH v3 2/8] xfs: flush dirty pagecache over hole in zoned mode zero range

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

[PATCH v3 3/8] iomap, xfs: lift zero range hole mapping flush into xfs

[Brian Foster]

iomap zero range has a wart in that it also flushes dirty pagecache
over hole mappings (rather than only unwritten mappings). This was
included to accommodate a quirk in XFS where COW fork preallocation
can exist over a hole in the data fork, and the associated range is
reported as a hole. This is because the range actually is a hole,
but XFS also has an optimization where if COW fork blocks exist for
a range being written to, those blocks are used regardless of
whether the data fork blocks are shared or not. For zeroing, COW
fork blocks over a data fork hole are only relevant if the range is
dirty in pagecache, otherwise the range is already considered
zeroed.

The easiest way to deal with this corner case is to flush the
pagecache to trigger COW remapping into the data fork, and then
operate on the updated on-disk state. The problem is that ext4
cannot accommodate a flush from this context due to being a
transaction deadlock vector.

Outside of the hole quirk, ext4 can avoid the flush for zero range
by using the recently introduced folio batch lookup mechanism for
unwritten mappings. Therefore, take the next logical step and lift
the hole handling logic into the XFS iomap_begin handler. iomap will
still flush on unwritten mappings without a folio batch, and XFS
will flush and retry mapping lookups in the case where it would
otherwise report a hole with dirty pagecache during a zero range.

Note that this is intended to be a fairly straightforward lift and
otherwise not change behavior. Now that the flush exists within XFS,
follow on patches can further optimize it.

Signed-off-by: Brian Foster <bfoster@redhat.com>
---
 fs/iomap/buffered-io.c |  2 +-
 fs/xfs/xfs_iomap.c     | 25 ++++++++++++++++++++++---
 2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index bc82083e420a..0999aca6e5cc 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -1642,7 +1642,7 @@ iomap_zero_range(struct inode *inode, loff_t pos, loff_t len, bool *did_zero,
 		     srcmap->type == IOMAP_UNWRITTEN)) {
 			s64 status;
 
-			if (range_dirty) {
+			if (range_dirty && srcmap->type == IOMAP_UNWRITTEN) {
 				range_dirty = false;
 				status = iomap_zero_iter_flush_and_stale(&iter);
 			} else {
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 0e323e4e304b..966fb9d8b9df 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -1811,6 +1811,7 @@ xfs_buffered_write_iomap_begin(
 	if (error)
 		return error;
 
+restart:
 	error = xfs_ilock_for_iomap(ip, flags, &lockmode);
 	if (error)
 		return error;
@@ -1838,9 +1839,27 @@ xfs_buffered_write_iomap_begin(
 	if (eof)
 		imap.br_startoff = end_fsb; /* fake hole until the end */
 
-	/* We never need to allocate blocks for zeroing or unsharing a hole. */
-	if ((flags & (IOMAP_UNSHARE | IOMAP_ZERO)) &&
-	    imap.br_startoff > offset_fsb) {
+	/* We never need to allocate blocks for unsharing a hole. */
+	if ((flags & IOMAP_UNSHARE) && imap.br_startoff > offset_fsb) {
+		xfs_hole_to_iomap(ip, iomap, offset_fsb, imap.br_startoff);
+		goto out_unlock;
+	}
+
+	/*
+	 * We may need to zero over a hole in the data fork if it's fronted by
+	 * COW blocks and dirty pagecache. To make sure zeroing occurs, force
+	 * writeback to remap pending blocks and restart the lookup.
+	 */
+	if ((flags & IOMAP_ZERO) && imap.br_startoff > offset_fsb) {
+		if (filemap_range_needs_writeback(inode->i_mapping, offset,
+						  offset + count - 1)) {
+			xfs_iunlock(ip, lockmode);
+			error = filemap_write_and_wait_range(inode->i_mapping,
+						offset, offset + count - 1);
+			if (error)
+				return error;
+			goto restart;
+		}
 		xfs_hole_to_iomap(ip, iomap, offset_fsb, imap.br_startoff);
 		goto out_unlock;
 	}
-- 
2.52.0

Re: [PATCH v3 3/8] iomap, xfs: lift zero range hole mapping flush into xfs

[Darrick J. Wong]

On Mon, Mar 09, 2026 at 09:45:01AM -0400, Brian Foster wrote:
> iomap zero range has a wart in that it also flushes dirty pagecache
> over hole mappings (rather than only unwritten mappings). This was
> included to accommodate a quirk in XFS where COW fork preallocation
> can exist over a hole in the data fork, and the associated range is
> reported as a hole. This is because the range actually is a hole,
> but XFS also has an optimization where if COW fork blocks exist for
> a range being written to, those blocks are used regardless of
> whether the data fork blocks are shared or not. For zeroing, COW
> fork blocks over a data fork hole are only relevant if the range is
> dirty in pagecache, otherwise the range is already considered
> zeroed.
> 
> The easiest way to deal with this corner case is to flush the
> pagecache to trigger COW remapping into the data fork, and then
> operate on the updated on-disk state. The problem is that ext4
> cannot accommodate a flush from this context due to being a
> transaction deadlock vector.
> 
> Outside of the hole quirk, ext4 can avoid the flush for zero range
> by using the recently introduced folio batch lookup mechanism for
> unwritten mappings. Therefore, take the next logical step and lift
> the hole handling logic into the XFS iomap_begin handler. iomap will
> still flush on unwritten mappings without a folio batch, and XFS
> will flush and retry mapping lookups in the case where it would
> otherwise report a hole with dirty pagecache during a zero range.
> 
> Note that this is intended to be a fairly straightforward lift and
> otherwise not change behavior. Now that the flush exists within XFS,
> follow on patches can further optimize it.
> 
> Signed-off-by: Brian Foster <bfoster@redhat.com>
> ---
>  fs/iomap/buffered-io.c |  2 +-
>  fs/xfs/xfs_iomap.c     | 25 ++++++++++++++++++++++---
>  2 files changed, 23 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index bc82083e420a..0999aca6e5cc 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -1642,7 +1642,7 @@ iomap_zero_range(struct inode *inode, loff_t pos, loff_t len, bool *did_zero,
>  		     srcmap->type == IOMAP_UNWRITTEN)) {
>  			s64 status;
>  
> -			if (range_dirty) {
> +			if (range_dirty && srcmap->type == IOMAP_UNWRITTEN) {
>  				range_dirty = false;
>  				status = iomap_zero_iter_flush_and_stale(&iter);
>  			} else {
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index 0e323e4e304b..966fb9d8b9df 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -1811,6 +1811,7 @@ xfs_buffered_write_iomap_begin(
>  	if (error)
>  		return error;
>  
> +restart:
>  	error = xfs_ilock_for_iomap(ip, flags, &lockmode);
>  	if (error)
>  		return error;
> @@ -1838,9 +1839,27 @@ xfs_buffered_write_iomap_begin(
>  	if (eof)
>  		imap.br_startoff = end_fsb; /* fake hole until the end */
>  
> -	/* We never need to allocate blocks for zeroing or unsharing a hole. */
> -	if ((flags & (IOMAP_UNSHARE | IOMAP_ZERO)) &&
> -	    imap.br_startoff > offset_fsb) {
> +	/* We never need to allocate blocks for unsharing a hole. */
> +	if ((flags & IOMAP_UNSHARE) && imap.br_startoff > offset_fsb) {
> +		xfs_hole_to_iomap(ip, iomap, offset_fsb, imap.br_startoff);
> +		goto out_unlock;
> +	}
> +
> +	/*
> +	 * We may need to zero over a hole in the data fork if it's fronted by
> +	 * COW blocks and dirty pagecache. To make sure zeroing occurs, force
> +	 * writeback to remap pending blocks and restart the lookup.
> +	 */
> +	if ((flags & IOMAP_ZERO) && imap.br_startoff > offset_fsb) {
> +		if (filemap_range_needs_writeback(inode->i_mapping, offset,
> +						  offset + count - 1)) {
> +			xfs_iunlock(ip, lockmode);
> +			error = filemap_write_and_wait_range(inode->i_mapping,
> +						offset, offset + count - 1);

Two tab indent here, but other than that nit this makes sense to me.
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

--D

> +			if (error)
> +				return error;
> +			goto restart;
> +		}
>  		xfs_hole_to_iomap(ip, iomap, offset_fsb, imap.br_startoff);
>  		goto out_unlock;
>  	}
> -- 
> 2.52.0
> 
> 

Re: [PATCH v3 3/8] iomap, xfs: lift zero range hole mapping flush into xfs

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

[PATCH v3 4/8] xfs: flush eof folio before insert range size update

[Brian Foster]

The flush in xfs_buffered_write_iomap_begin() for zero range over a
data fork hole fronted by COW fork prealloc is primarily designed to
provide correct zeroing behavior in particular pagecache conditions.
As it turns out, this also partially masks some odd behavior in
insert range (via zero range via setattr).

Insert range bumps i_size the length of the new range, flushes,
unmaps pagecache and cancels COW prealloc, and then right shifts
extents from the end of the file back to the target offset of the
insert. Since the i_size update occurs before the pagecache flush,
this creates a transient situation where writeback around EOF can
behave differently.

This appears to be corner case situation, but if happens to be
fronted by COW fork speculative preallocation and a large, dirty
folio that contains at least one full COW block beyond EOF, the
writeback after i_size is bumped may remap that COW fork block into
the data fork within EOF. The block is zeroed and then shifted back
out to post-eof, but this is unexpected in that it leads to a
written post-eof data fork block. This can cause a zero range
warning on a subsequent size extension, because we should never find
blocks that require physical zeroing beyond i_size.

To avoid this quirk, flush the EOF folio before the i_size update
during insert range. The entire range will be flushed, unmapped and
invalidated anyways, so this should be relatively unnoticeable.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/xfs_file.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 6246f34df9fd..48d812b99282 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -1263,6 +1263,23 @@ xfs_falloc_insert_range(
 	if (offset >= isize)
 		return -EINVAL;
 
+	/*
+	 * Let writeback clean up EOF folio state before we bump i_size. The
+	 * insert flushes before it starts shifting and under certain
+	 * circumstances we can write back blocks that should technically be
+	 * considered post-eof (and thus should not be submitted for writeback).
+	 *
+	 * For example, a large, dirty folio that spans EOF and is backed by
+	 * post-eof COW fork preallocation can cause block remap into the data
+	 * fork. This shifts back out beyond EOF, but creates an expectedly
+	 * written post-eof block. The insert is going to flush, unmap and
+	 * cancel prealloc across this whole range, so flush EOF now before we
+	 * bump i_size to provide consistent behavior.
+	 */
+	error = filemap_write_and_wait_range(inode->i_mapping, isize, isize);
+	if (error)
+		return error;
+
 	error = xfs_falloc_setsize(file, isize + len);
 	if (error)
 		return error;
-- 
2.52.0

Re: [PATCH v3 4/8] xfs: flush eof folio before insert range size update

[Darrick J. Wong]

On Mon, Mar 09, 2026 at 09:45:02AM -0400, Brian Foster wrote:
> The flush in xfs_buffered_write_iomap_begin() for zero range over a
> data fork hole fronted by COW fork prealloc is primarily designed to
> provide correct zeroing behavior in particular pagecache conditions.
> As it turns out, this also partially masks some odd behavior in
> insert range (via zero range via setattr).
> 
> Insert range bumps i_size the length of the new range, flushes,
> unmaps pagecache and cancels COW prealloc, and then right shifts
> extents from the end of the file back to the target offset of the
> insert. Since the i_size update occurs before the pagecache flush,
> this creates a transient situation where writeback around EOF can
> behave differently.
> 
> This appears to be corner case situation, but if happens to be
> fronted by COW fork speculative preallocation and a large, dirty
> folio that contains at least one full COW block beyond EOF, the

How do we get a large dirty folio with at least one full cow block
beyond i_size?  If we did a pagecache write to the file, then at least
the incore isize should have been boosted out far enough that the block
will now be inside EOF, right?

--D

> writeback after i_size is bumped may remap that COW fork block into
> the data fork within EOF. The block is zeroed and then shifted back
> out to post-eof, but this is unexpected in that it leads to a
> written post-eof data fork block. This can cause a zero range
> warning on a subsequent size extension, because we should never find
> blocks that require physical zeroing beyond i_size.
> 
> To avoid this quirk, flush the EOF folio before the i_size update
> during insert range. The entire range will be flushed, unmapped and
> invalidated anyways, so this should be relatively unnoticeable.
> 
> Signed-off-by: Brian Foster <bfoster@redhat.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> ---
>  fs/xfs/xfs_file.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index 6246f34df9fd..48d812b99282 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -1263,6 +1263,23 @@ xfs_falloc_insert_range(
>  	if (offset >= isize)
>  		return -EINVAL;
>  
> +	/*
> +	 * Let writeback clean up EOF folio state before we bump i_size. The
> +	 * insert flushes before it starts shifting and under certain
> +	 * circumstances we can write back blocks that should technically be
> +	 * considered post-eof (and thus should not be submitted for writeback).
> +	 *
> +	 * For example, a large, dirty folio that spans EOF and is backed by
> +	 * post-eof COW fork preallocation can cause block remap into the data
> +	 * fork. This shifts back out beyond EOF, but creates an expectedly
> +	 * written post-eof block. The insert is going to flush, unmap and
> +	 * cancel prealloc across this whole range, so flush EOF now before we
> +	 * bump i_size to provide consistent behavior.
> +	 */
> +	error = filemap_write_and_wait_range(inode->i_mapping, isize, isize);
> +	if (error)
> +		return error;
> +
>  	error = xfs_falloc_setsize(file, isize + len);
>  	if (error)
>  		return error;
> -- 
> 2.52.0
> 
> 

Re: [PATCH v3 4/8] xfs: flush eof folio before insert range size update

[Brian Foster]

On Mon, Mar 09, 2026 at 10:32:13AM -0700, Darrick J. Wong wrote:
> On Mon, Mar 09, 2026 at 09:45:02AM -0400, Brian Foster wrote:
> > The flush in xfs_buffered_write_iomap_begin() for zero range over a
> > data fork hole fronted by COW fork prealloc is primarily designed to
> > provide correct zeroing behavior in particular pagecache conditions.
> > As it turns out, this also partially masks some odd behavior in
> > insert range (via zero range via setattr).
> > 
> > Insert range bumps i_size the length of the new range, flushes,
> > unmaps pagecache and cancels COW prealloc, and then right shifts
> > extents from the end of the file back to the target offset of the
> > insert. Since the i_size update occurs before the pagecache flush,
> > this creates a transient situation where writeback around EOF can
> > behave differently.
> > 
> > This appears to be corner case situation, but if happens to be
> > fronted by COW fork speculative preallocation and a large, dirty
> > folio that contains at least one full COW block beyond EOF, the
> 
> How do we get a large dirty folio with at least one full cow block
> beyond i_size?  If we did a pagecache write to the file, then at least
> the incore isize should have been boosted out far enough that the block
> will now be inside EOF, right?
> 

It's been quite some time since I first reproduced and diagnosed this so
I'm going from memory, but IIRC it was some odd case like a failure to
split a large folio fully within EOF on a truncate down across it due to
being dirty. I originally thought the large folio thing was actually the
issue, but I don't recall seeing anything that prevents it in this
particular situation. So my understanding from that is that it's more
unexpected in that we wouldn't create a large folio directly in this
situation, but it's still technically possible through oddball fsx
sequences.

From there, we can run into the insert situation described above where
the i_size update -> flush -> extent shift behavior creates a transient
situation where a post-eof block is temporarily within eof.

Brian

> --D
> 
> > writeback after i_size is bumped may remap that COW fork block into
> > the data fork within EOF. The block is zeroed and then shifted back
> > out to post-eof, but this is unexpected in that it leads to a
> > written post-eof data fork block. This can cause a zero range
> > warning on a subsequent size extension, because we should never find
> > blocks that require physical zeroing beyond i_size.
> > 
> > To avoid this quirk, flush the EOF folio before the i_size update
> > during insert range. The entire range will be flushed, unmapped and
> > invalidated anyways, so this should be relatively unnoticeable.
> > 
> > Signed-off-by: Brian Foster <bfoster@redhat.com>
> > Reviewed-by: Christoph Hellwig <hch@lst.de>
> > ---
> >  fs/xfs/xfs_file.c | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> > 
> > diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> > index 6246f34df9fd..48d812b99282 100644
> > --- a/fs/xfs/xfs_file.c
> > +++ b/fs/xfs/xfs_file.c
> > @@ -1263,6 +1263,23 @@ xfs_falloc_insert_range(
> >  	if (offset >= isize)
> >  		return -EINVAL;
> >  
> > +	/*
> > +	 * Let writeback clean up EOF folio state before we bump i_size. The
> > +	 * insert flushes before it starts shifting and under certain
> > +	 * circumstances we can write back blocks that should technically be
> > +	 * considered post-eof (and thus should not be submitted for writeback).
> > +	 *
> > +	 * For example, a large, dirty folio that spans EOF and is backed by
> > +	 * post-eof COW fork preallocation can cause block remap into the data
> > +	 * fork. This shifts back out beyond EOF, but creates an expectedly
> > +	 * written post-eof block. The insert is going to flush, unmap and
> > +	 * cancel prealloc across this whole range, so flush EOF now before we
> > +	 * bump i_size to provide consistent behavior.
> > +	 */
> > +	error = filemap_write_and_wait_range(inode->i_mapping, isize, isize);
> > +	if (error)
> > +		return error;
> > +
> >  	error = xfs_falloc_setsize(file, isize + len);
> >  	if (error)
> >  		return error;
> > -- 
> > 2.52.0
> > 
> > 
> 

[PATCH v3 5/8] xfs: look up cow fork extent earlier for buffered iomap_begin

[Brian Foster]

To further isolate the need for flushing for zero range, we need to
know whether a hole in the data fork is fronted by blocks in the COW
fork or not. COW fork lookup currently occurs further down in the
function, after the zero range case is handled.

As a preparation step, lift the COW fork extent lookup to earlier in
the function, at the same time as the data fork lookup. Only the
lookup logic is lifted. The COW fork branch/reporting logic remains
as is to avoid any observable behavior change from an iomap
reporting perspective.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/xfs_iomap.c | 46 +++++++++++++++++++++++++---------------------
 1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 966fb9d8b9df..0f44d9aef25b 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -1830,14 +1830,29 @@ xfs_buffered_write_iomap_begin(
 		goto out_unlock;
 
 	/*
-	 * Search the data fork first to look up our source mapping.  We
-	 * always need the data fork map, as we have to return it to the
-	 * iomap code so that the higher level write code can read data in to
-	 * perform read-modify-write cycles for unaligned writes.
+	 * Search the data fork first to look up our source mapping. We always
+	 * need the data fork map, as we have to return it to the iomap code so
+	 * that the higher level write code can read data in to perform
+	 * read-modify-write cycles for unaligned writes.
+	 *
+	 * Then search the COW fork extent list even if we did not find a data
+	 * fork extent. This serves two purposes: first this implements the
+	 * speculative preallocation using cowextsize, so that we also unshare
+	 * block adjacent to shared blocks instead of just the shared blocks
+	 * themselves. Second the lookup in the extent list is generally faster
+	 * than going out to the shared extent tree.
 	 */
 	eof = !xfs_iext_lookup_extent(ip, &ip->i_df, offset_fsb, &icur, &imap);
 	if (eof)
 		imap.br_startoff = end_fsb; /* fake hole until the end */
+	if (xfs_is_cow_inode(ip)) {
+		if (!ip->i_cowfp) {
+			ASSERT(!xfs_is_reflink_inode(ip));
+			xfs_ifork_init_cow(ip);
+		}
+		cow_eof = !xfs_iext_lookup_extent(ip, ip->i_cowfp, offset_fsb,
+				&ccur, &cmap);
+	}
 
 	/* We never need to allocate blocks for unsharing a hole. */
 	if ((flags & IOMAP_UNSHARE) && imap.br_startoff > offset_fsb) {
@@ -1904,24 +1919,13 @@ xfs_buffered_write_iomap_begin(
 	}
 
 	/*
-	 * Search the COW fork extent list even if we did not find a data fork
-	 * extent.  This serves two purposes: first this implements the
-	 * speculative preallocation using cowextsize, so that we also unshare
-	 * block adjacent to shared blocks instead of just the shared blocks
-	 * themselves.  Second the lookup in the extent list is generally faster
-	 * than going out to the shared extent tree.
+	 * Now that we've handled any operation specific special cases, at this
+	 * point we can report a COW mapping if found.
 	 */
-	if (xfs_is_cow_inode(ip)) {
-		if (!ip->i_cowfp) {
-			ASSERT(!xfs_is_reflink_inode(ip));
-			xfs_ifork_init_cow(ip);
-		}
-		cow_eof = !xfs_iext_lookup_extent(ip, ip->i_cowfp, offset_fsb,
-				&ccur, &cmap);
-		if (!cow_eof && cmap.br_startoff <= offset_fsb) {
-			trace_xfs_reflink_cow_found(ip, &cmap);
-			goto found_cow;
-		}
+	if (xfs_is_cow_inode(ip) &&
+	    !cow_eof && cmap.br_startoff <= offset_fsb) {
+		trace_xfs_reflink_cow_found(ip, &cmap);
+		goto found_cow;
 	}
 
 	if (imap.br_startoff <= offset_fsb) {
-- 
2.52.0

[PATCH v3 6/8] xfs: only flush when COW fork blocks overlap data fork holes

[Brian Foster]

The zero range hole mapping flush case has been lifted from iomap
into XFS. Now that we have more mapping context available from the
->iomap_begin() handler, we can isolate the flush further to when we
know a hole is fronted by COW blocks.

Rather than purely rely on pagecache dirty state, explicitly check
for the case where a range is a hole in both forks. Otherwise trim
to the range where there does happen to be overlap and use that for
the pagecache writeback check. This might prevent some spurious
zeroing, but more importantly makes it easier to remove the flush
entirely.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/xfs/xfs_iomap.c | 36 ++++++++++++++++++++++++++++++------
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 0f44d9aef25b..ce342b9ce2f0 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -1781,10 +1781,12 @@ xfs_buffered_write_iomap_begin(
 {
 	struct iomap_iter	*iter = container_of(iomap, struct iomap_iter,
 						     iomap);
+	struct address_space	*mapping = inode->i_mapping;
 	struct xfs_inode	*ip = XFS_I(inode);
 	struct xfs_mount	*mp = ip->i_mount;
 	xfs_fileoff_t		offset_fsb = XFS_B_TO_FSBT(mp, offset);
 	xfs_fileoff_t		end_fsb = xfs_iomap_end_fsb(mp, offset, count);
+	xfs_fileoff_t		cow_fsb = NULLFILEOFF;
 	struct xfs_bmbt_irec	imap, cmap;
 	struct xfs_iext_cursor	icur, ccur;
 	xfs_fsblock_t		prealloc_blocks = 0;
@@ -1852,6 +1854,8 @@ xfs_buffered_write_iomap_begin(
 		}
 		cow_eof = !xfs_iext_lookup_extent(ip, ip->i_cowfp, offset_fsb,
 				&ccur, &cmap);
+		if (!cow_eof)
+			cow_fsb = cmap.br_startoff;
 	}
 
 	/* We never need to allocate blocks for unsharing a hole. */
@@ -1866,17 +1870,37 @@ xfs_buffered_write_iomap_begin(
 	 * writeback to remap pending blocks and restart the lookup.
 	 */
 	if ((flags & IOMAP_ZERO) && imap.br_startoff > offset_fsb) {
-		if (filemap_range_needs_writeback(inode->i_mapping, offset,
-						  offset + count - 1)) {
+		loff_t	start, end;
+
+		imap.br_blockcount = imap.br_startoff - offset_fsb;
+		imap.br_startoff = offset_fsb;
+		imap.br_startblock = HOLESTARTBLOCK;
+		imap.br_state = XFS_EXT_NORM;
+
+		if (cow_fsb == NULLFILEOFF)
+			goto found_imap;
+		if (cow_fsb > offset_fsb) {
+			xfs_trim_extent(&imap, offset_fsb,
+					cow_fsb - offset_fsb);
+			goto found_imap;
+		}
+
+		/* COW fork blocks overlap the hole */
+		xfs_trim_extent(&imap, offset_fsb,
+			    cmap.br_startoff + cmap.br_blockcount - offset_fsb);
+		start = XFS_FSB_TO_B(mp, imap.br_startoff);
+		end = XFS_FSB_TO_B(mp,
+				   imap.br_startoff + imap.br_blockcount) - 1;
+		if (filemap_range_needs_writeback(mapping, start, end)) {
 			xfs_iunlock(ip, lockmode);
-			error = filemap_write_and_wait_range(inode->i_mapping,
-						offset, offset + count - 1);
+			error = filemap_write_and_wait_range(mapping, start,
+							     end);
 			if (error)
 				return error;
 			goto restart;
 		}
-		xfs_hole_to_iomap(ip, iomap, offset_fsb, imap.br_startoff);
-		goto out_unlock;
+
+		goto found_imap;
 	}
 
 	/*
-- 
2.52.0

Re: [PATCH v3 6/8] xfs: only flush when COW fork blocks overlap data fork holes

[Darrick J. Wong]

On Mon, Mar 09, 2026 at 09:45:04AM -0400, Brian Foster wrote:
> The zero range hole mapping flush case has been lifted from iomap
> into XFS. Now that we have more mapping context available from the
> ->iomap_begin() handler, we can isolate the flush further to when we
> know a hole is fronted by COW blocks.
> 
> Rather than purely rely on pagecache dirty state, explicitly check
> for the case where a range is a hole in both forks. Otherwise trim
> to the range where there does happen to be overlap and use that for
> the pagecache writeback check. This might prevent some spurious
> zeroing, but more importantly makes it easier to remove the flush
> entirely.
> 
> Signed-off-by: Brian Foster <bfoster@redhat.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>

Makes sense,
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

--D

> ---
>  fs/xfs/xfs_iomap.c | 36 ++++++++++++++++++++++++++++++------
>  1 file changed, 30 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index 0f44d9aef25b..ce342b9ce2f0 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -1781,10 +1781,12 @@ xfs_buffered_write_iomap_begin(
>  {
>  	struct iomap_iter	*iter = container_of(iomap, struct iomap_iter,
>  						     iomap);
> +	struct address_space	*mapping = inode->i_mapping;
>  	struct xfs_inode	*ip = XFS_I(inode);
>  	struct xfs_mount	*mp = ip->i_mount;
>  	xfs_fileoff_t		offset_fsb = XFS_B_TO_FSBT(mp, offset);
>  	xfs_fileoff_t		end_fsb = xfs_iomap_end_fsb(mp, offset, count);
> +	xfs_fileoff_t		cow_fsb = NULLFILEOFF;
>  	struct xfs_bmbt_irec	imap, cmap;
>  	struct xfs_iext_cursor	icur, ccur;
>  	xfs_fsblock_t		prealloc_blocks = 0;
> @@ -1852,6 +1854,8 @@ xfs_buffered_write_iomap_begin(
>  		}
>  		cow_eof = !xfs_iext_lookup_extent(ip, ip->i_cowfp, offset_fsb,
>  				&ccur, &cmap);
> +		if (!cow_eof)
> +			cow_fsb = cmap.br_startoff;
>  	}
>  
>  	/* We never need to allocate blocks for unsharing a hole. */
> @@ -1866,17 +1870,37 @@ xfs_buffered_write_iomap_begin(
>  	 * writeback to remap pending blocks and restart the lookup.
>  	 */
>  	if ((flags & IOMAP_ZERO) && imap.br_startoff > offset_fsb) {
> -		if (filemap_range_needs_writeback(inode->i_mapping, offset,
> -						  offset + count - 1)) {
> +		loff_t	start, end;
> +
> +		imap.br_blockcount = imap.br_startoff - offset_fsb;
> +		imap.br_startoff = offset_fsb;
> +		imap.br_startblock = HOLESTARTBLOCK;
> +		imap.br_state = XFS_EXT_NORM;
> +
> +		if (cow_fsb == NULLFILEOFF)
> +			goto found_imap;
> +		if (cow_fsb > offset_fsb) {
> +			xfs_trim_extent(&imap, offset_fsb,
> +					cow_fsb - offset_fsb);
> +			goto found_imap;
> +		}
> +
> +		/* COW fork blocks overlap the hole */
> +		xfs_trim_extent(&imap, offset_fsb,
> +			    cmap.br_startoff + cmap.br_blockcount - offset_fsb);
> +		start = XFS_FSB_TO_B(mp, imap.br_startoff);
> +		end = XFS_FSB_TO_B(mp,
> +				   imap.br_startoff + imap.br_blockcount) - 1;
> +		if (filemap_range_needs_writeback(mapping, start, end)) {
>  			xfs_iunlock(ip, lockmode);
> -			error = filemap_write_and_wait_range(inode->i_mapping,
> -						offset, offset + count - 1);
> +			error = filemap_write_and_wait_range(mapping, start,
> +							     end);
>  			if (error)
>  				return error;
>  			goto restart;
>  		}
> -		xfs_hole_to_iomap(ip, iomap, offset_fsb, imap.br_startoff);
> -		goto out_unlock;
> +
> +		goto found_imap;
>  	}
>  
>  	/*
> -- 
> 2.52.0
> 
> 

[PATCH v3 7/8] xfs: replace zero range flush with folio batch

[Brian Foster]

Now that the zero range pagecache flush is purely isolated to
providing zeroing correctness in this case, we can remove it and
replace it with the folio batch mechanism that is used for handling
unwritten extents.

This is still slightly odd in that XFS reports a hole vs. a mapping
that reflects the COW fork extents, but that has always been the
case in this situation and so a separate issue. We drop the iomap
warning that assumes the folio batch is always associated with
unwritten mappings, but this is mainly a development assertion as
otherwise the core iomap fbatch code doesn't care much about the
mapping type if it's handed the set of folios to process.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
---
 fs/iomap/buffered-io.c |  4 ----
 fs/xfs/xfs_iomap.c     | 20 ++++++--------------
 2 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 0999aca6e5cc..4422a6d477d7 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -1633,10 +1633,6 @@ iomap_zero_range(struct inode *inode, loff_t pos, loff_t len, bool *did_zero,
 	while ((ret = iomap_iter(&iter, ops)) > 0) {
 		const struct iomap *srcmap = iomap_iter_srcmap(&iter);
 
-		if (WARN_ON_ONCE((iter.iomap.flags & IOMAP_F_FOLIO_BATCH) &&
-				 srcmap->type != IOMAP_UNWRITTEN))
-			return -EIO;
-
 		if (!(iter.iomap.flags & IOMAP_F_FOLIO_BATCH) &&
 		    (srcmap->type == IOMAP_HOLE ||
 		     srcmap->type == IOMAP_UNWRITTEN)) {
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index ce342b9ce2f0..df240931f07a 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -1781,7 +1781,6 @@ xfs_buffered_write_iomap_begin(
 {
 	struct iomap_iter	*iter = container_of(iomap, struct iomap_iter,
 						     iomap);
-	struct address_space	*mapping = inode->i_mapping;
 	struct xfs_inode	*ip = XFS_I(inode);
 	struct xfs_mount	*mp = ip->i_mount;
 	xfs_fileoff_t		offset_fsb = XFS_B_TO_FSBT(mp, offset);
@@ -1813,7 +1812,6 @@ xfs_buffered_write_iomap_begin(
 	if (error)
 		return error;
 
-restart:
 	error = xfs_ilock_for_iomap(ip, flags, &lockmode);
 	if (error)
 		return error;
@@ -1866,8 +1864,8 @@ xfs_buffered_write_iomap_begin(
 
 	/*
 	 * We may need to zero over a hole in the data fork if it's fronted by
-	 * COW blocks and dirty pagecache. To make sure zeroing occurs, force
-	 * writeback to remap pending blocks and restart the lookup.
+	 * COW blocks and dirty pagecache. Scan such file ranges for dirty
+	 * cache and fill the iomap batch with folios that need zeroing.
 	 */
 	if ((flags & IOMAP_ZERO) && imap.br_startoff > offset_fsb) {
 		loff_t	start, end;
@@ -1889,16 +1887,10 @@ xfs_buffered_write_iomap_begin(
 		xfs_trim_extent(&imap, offset_fsb,
 			    cmap.br_startoff + cmap.br_blockcount - offset_fsb);
 		start = XFS_FSB_TO_B(mp, imap.br_startoff);
-		end = XFS_FSB_TO_B(mp,
-				   imap.br_startoff + imap.br_blockcount) - 1;
-		if (filemap_range_needs_writeback(mapping, start, end)) {
-			xfs_iunlock(ip, lockmode);
-			error = filemap_write_and_wait_range(mapping, start,
-							     end);
-			if (error)
-				return error;
-			goto restart;
-		}
+		end = XFS_FSB_TO_B(mp, imap.br_startoff + imap.br_blockcount);
+		iomap_fill_dirty_folios(iter, &start, end, &iomap_flags);
+		xfs_trim_extent(&imap, offset_fsb,
+				XFS_B_TO_FSB(mp, start) - offset_fsb);
 
 		goto found_imap;
 	}
-- 
2.52.0

Re: [PATCH v3 7/8] xfs: replace zero range flush with folio batch

[Darrick J. Wong]

On Mon, Mar 09, 2026 at 09:45:05AM -0400, Brian Foster wrote:
> Now that the zero range pagecache flush is purely isolated to
> providing zeroing correctness in this case, we can remove it and
> replace it with the folio batch mechanism that is used for handling
> unwritten extents.
> 
> This is still slightly odd in that XFS reports a hole vs. a mapping
> that reflects the COW fork extents, but that has always been the
> case in this situation and so a separate issue. We drop the iomap
> warning that assumes the folio batch is always associated with
> unwritten mappings, but this is mainly a development assertion as
> otherwise the core iomap fbatch code doesn't care much about the
> mapping type if it's handed the set of folios to process.
> 
> Signed-off-by: Brian Foster <bfoster@redhat.com>
> Reviewed-by: Christoph Hellwig <hch@lst.de>

This is (in the end) a much cleaner solution :)
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

--D

> ---
>  fs/iomap/buffered-io.c |  4 ----
>  fs/xfs/xfs_iomap.c     | 20 ++++++--------------
>  2 files changed, 6 insertions(+), 18 deletions(-)
> 
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index 0999aca6e5cc..4422a6d477d7 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -1633,10 +1633,6 @@ iomap_zero_range(struct inode *inode, loff_t pos, loff_t len, bool *did_zero,
>  	while ((ret = iomap_iter(&iter, ops)) > 0) {
>  		const struct iomap *srcmap = iomap_iter_srcmap(&iter);
>  
> -		if (WARN_ON_ONCE((iter.iomap.flags & IOMAP_F_FOLIO_BATCH) &&
> -				 srcmap->type != IOMAP_UNWRITTEN))
> -			return -EIO;
> -
>  		if (!(iter.iomap.flags & IOMAP_F_FOLIO_BATCH) &&
>  		    (srcmap->type == IOMAP_HOLE ||
>  		     srcmap->type == IOMAP_UNWRITTEN)) {
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index ce342b9ce2f0..df240931f07a 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -1781,7 +1781,6 @@ xfs_buffered_write_iomap_begin(
>  {
>  	struct iomap_iter	*iter = container_of(iomap, struct iomap_iter,
>  						     iomap);
> -	struct address_space	*mapping = inode->i_mapping;
>  	struct xfs_inode	*ip = XFS_I(inode);
>  	struct xfs_mount	*mp = ip->i_mount;
>  	xfs_fileoff_t		offset_fsb = XFS_B_TO_FSBT(mp, offset);
> @@ -1813,7 +1812,6 @@ xfs_buffered_write_iomap_begin(
>  	if (error)
>  		return error;
>  
> -restart:
>  	error = xfs_ilock_for_iomap(ip, flags, &lockmode);
>  	if (error)
>  		return error;
> @@ -1866,8 +1864,8 @@ xfs_buffered_write_iomap_begin(
>  
>  	/*
>  	 * We may need to zero over a hole in the data fork if it's fronted by
> -	 * COW blocks and dirty pagecache. To make sure zeroing occurs, force
> -	 * writeback to remap pending blocks and restart the lookup.
> +	 * COW blocks and dirty pagecache. Scan such file ranges for dirty
> +	 * cache and fill the iomap batch with folios that need zeroing.
>  	 */
>  	if ((flags & IOMAP_ZERO) && imap.br_startoff > offset_fsb) {
>  		loff_t	start, end;
> @@ -1889,16 +1887,10 @@ xfs_buffered_write_iomap_begin(
>  		xfs_trim_extent(&imap, offset_fsb,
>  			    cmap.br_startoff + cmap.br_blockcount - offset_fsb);
>  		start = XFS_FSB_TO_B(mp, imap.br_startoff);
> -		end = XFS_FSB_TO_B(mp,
> -				   imap.br_startoff + imap.br_blockcount) - 1;
> -		if (filemap_range_needs_writeback(mapping, start, end)) {
> -			xfs_iunlock(ip, lockmode);
> -			error = filemap_write_and_wait_range(mapping, start,
> -							     end);
> -			if (error)
> -				return error;
> -			goto restart;
> -		}
> +		end = XFS_FSB_TO_B(mp, imap.br_startoff + imap.br_blockcount);
> +		iomap_fill_dirty_folios(iter, &start, end, &iomap_flags);
> +		xfs_trim_extent(&imap, offset_fsb,
> +				XFS_B_TO_FSB(mp, start) - offset_fsb);
>  
>  		goto found_imap;
>  	}
> -- 
> 2.52.0
> 
> 

[PATCH v3 8/8] xfs: report cow mappings with dirty pagecache for iomap zero range

[Brian Foster]

XFS has long supported the case where it is possible to have dirty
data in pagecache backed by COW fork blocks and a hole in the data
fork. This occurs for two reasons. On reflink enabled files, COW
fork blocks are allocated with preallocation to help avoid
fragmention. Second, if a mapping lookup for a write finds blocks in
the COW fork, it consumes those blocks unconditionally. This might
mean that COW fork blocks are backed by non-shared blocks or even a
hole in the data fork, both of which are perfectly fine.

This leaves an odd corner case for zero range, however, because it
needs to distinguish between ranges that are sparse and thus do not
require zeroing and those that are not. A range backed by COW fork
blocks and a data fork hole might either be a legitimate hole in the
file or a range with pending buffered writes that will be written
back (which will remap COW fork blocks into the data fork).

This "COW fork blocks over data fork hole" situation has
historically been reported as a hole to iomap, which then has grown
a flush hack as a workaround to ensure zeroing occurs correctly. Now
that this has been lifted into the filesystem and replaced by the
dirty folio lookup mechanism, we can do better and use the pagecache
state to decide how to report the mapping. If a COW fork range
exists with dirty folios in cache, then report a typical shared
mapping. If the range is clean in cache, then we can consider the
COW blocks preallocation and call it a hole.

This doesn't fundamentally change behavior, but makes mapping
reporting more accurate. Note that this does require splitting
across the EOF boundary (similar to normal zero range) to ensure we
don't spuriously perform post-eof zeroing. iomap will warn about
zeroing beyond EOF because folios beyond i_size may not be written
back.

Signed-off-by: Brian Foster <bfoster@redhat.com>
---
 fs/xfs/xfs_iomap.c | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index df240931f07a..3bef5ea610bb 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -1786,6 +1786,7 @@ xfs_buffered_write_iomap_begin(
 	xfs_fileoff_t		offset_fsb = XFS_B_TO_FSBT(mp, offset);
 	xfs_fileoff_t		end_fsb = xfs_iomap_end_fsb(mp, offset, count);
 	xfs_fileoff_t		cow_fsb = NULLFILEOFF;
+	xfs_fileoff_t		eof_fsb = XFS_B_TO_FSB(mp, XFS_ISIZE(ip));
 	struct xfs_bmbt_irec	imap, cmap;
 	struct xfs_iext_cursor	icur, ccur;
 	xfs_fsblock_t		prealloc_blocks = 0;
@@ -1868,7 +1869,8 @@ xfs_buffered_write_iomap_begin(
 	 * cache and fill the iomap batch with folios that need zeroing.
 	 */
 	if ((flags & IOMAP_ZERO) && imap.br_startoff > offset_fsb) {
-		loff_t	start, end;
+		loff_t		start, end;
+		unsigned int	fbatch_count;
 
 		imap.br_blockcount = imap.br_startoff - offset_fsb;
 		imap.br_startoff = offset_fsb;
@@ -1883,15 +1885,32 @@ xfs_buffered_write_iomap_begin(
 			goto found_imap;
 		}
 
+		/* no zeroing beyond eof, so split at the boundary */
+		if (offset_fsb >= eof_fsb)
+			goto found_imap;
+		if (offset_fsb < eof_fsb && end_fsb > eof_fsb)
+			xfs_trim_extent(&imap, offset_fsb, eof_fsb - offset_fsb);
+
 		/* COW fork blocks overlap the hole */
 		xfs_trim_extent(&imap, offset_fsb,
 			    cmap.br_startoff + cmap.br_blockcount - offset_fsb);
 		start = XFS_FSB_TO_B(mp, imap.br_startoff);
 		end = XFS_FSB_TO_B(mp, imap.br_startoff + imap.br_blockcount);
-		iomap_fill_dirty_folios(iter, &start, end, &iomap_flags);
+		fbatch_count = iomap_fill_dirty_folios(iter, &start, end,
+						       &iomap_flags);
 		xfs_trim_extent(&imap, offset_fsb,
 				XFS_B_TO_FSB(mp, start) - offset_fsb);
 
+		/*
+		 * Report the COW mapping if we have folios to zero. Otherwise
+		 * ignore the COW blocks as preallocation and report a hole.
+		 */
+		if (fbatch_count) {
+			xfs_trim_extent(&cmap, imap.br_startoff,
+					imap.br_blockcount);
+			imap.br_startoff = end_fsb;	/* fake hole */
+			goto found_cow;
+		}
 		goto found_imap;
 	}
 
@@ -1901,8 +1920,6 @@ xfs_buffered_write_iomap_begin(
 	 * unwritten extent.
 	 */
 	if (flags & IOMAP_ZERO) {
-		xfs_fileoff_t eof_fsb = XFS_B_TO_FSB(mp, XFS_ISIZE(ip));
-
 		if (isnullstartblock(imap.br_startblock) &&
 		    offset_fsb >= eof_fsb)
 			goto convert_delay;
-- 
2.52.0

Re: [PATCH v3 8/8] xfs: report cow mappings with dirty pagecache for iomap zero range

[Darrick J. Wong]

On Mon, Mar 09, 2026 at 09:45:06AM -0400, Brian Foster wrote:
> XFS has long supported the case where it is possible to have dirty
> data in pagecache backed by COW fork blocks and a hole in the data
> fork. This occurs for two reasons. On reflink enabled files, COW
> fork blocks are allocated with preallocation to help avoid
> fragmention. Second, if a mapping lookup for a write finds blocks in
> the COW fork, it consumes those blocks unconditionally. This might
> mean that COW fork blocks are backed by non-shared blocks or even a
> hole in the data fork, both of which are perfectly fine.
> 
> This leaves an odd corner case for zero range, however, because it
> needs to distinguish between ranges that are sparse and thus do not
> require zeroing and those that are not. A range backed by COW fork
> blocks and a data fork hole might either be a legitimate hole in the
> file or a range with pending buffered writes that will be written
> back (which will remap COW fork blocks into the data fork).
> 
> This "COW fork blocks over data fork hole" situation has
> historically been reported as a hole to iomap, which then has grown
> a flush hack as a workaround to ensure zeroing occurs correctly. Now
> that this has been lifted into the filesystem and replaced by the
> dirty folio lookup mechanism, we can do better and use the pagecache
> state to decide how to report the mapping. If a COW fork range
> exists with dirty folios in cache, then report a typical shared
> mapping. If the range is clean in cache, then we can consider the
> COW blocks preallocation and call it a hole.
> 
> This doesn't fundamentally change behavior, but makes mapping
> reporting more accurate. Note that this does require splitting
> across the EOF boundary (similar to normal zero range) to ensure we
> don't spuriously perform post-eof zeroing. iomap will warn about
> zeroing beyond EOF because folios beyond i_size may not be written
> back.

Hrmm.  I wonder if IOMAP_REPORT should grow this new "expose dirty
unwritten cow fork mappings over a data fork hole" behavior too?  I
guess the only user of IOMAP_REPORT that might care is swapfile
activation, but that fsyncs the whole file to disk before starting the
iteration so I think it won't matter?

> Signed-off-by: Brian Foster <bfoster@redhat.com>

/me isn't sure he sees the point of doing this only for IOMAP_ZERO but
you're right that it's weird to pass a folio batch and a hole mapping to
iomap so

Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

--D

> ---
>  fs/xfs/xfs_iomap.c | 25 +++++++++++++++++++++----
>  1 file changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index df240931f07a..3bef5ea610bb 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -1786,6 +1786,7 @@ xfs_buffered_write_iomap_begin(
>  	xfs_fileoff_t		offset_fsb = XFS_B_TO_FSBT(mp, offset);
>  	xfs_fileoff_t		end_fsb = xfs_iomap_end_fsb(mp, offset, count);
>  	xfs_fileoff_t		cow_fsb = NULLFILEOFF;
> +	xfs_fileoff_t		eof_fsb = XFS_B_TO_FSB(mp, XFS_ISIZE(ip));
>  	struct xfs_bmbt_irec	imap, cmap;
>  	struct xfs_iext_cursor	icur, ccur;
>  	xfs_fsblock_t		prealloc_blocks = 0;
> @@ -1868,7 +1869,8 @@ xfs_buffered_write_iomap_begin(
>  	 * cache and fill the iomap batch with folios that need zeroing.
>  	 */
>  	if ((flags & IOMAP_ZERO) && imap.br_startoff > offset_fsb) {
> -		loff_t	start, end;
> +		loff_t		start, end;
> +		unsigned int	fbatch_count;
>  
>  		imap.br_blockcount = imap.br_startoff - offset_fsb;
>  		imap.br_startoff = offset_fsb;
> @@ -1883,15 +1885,32 @@ xfs_buffered_write_iomap_begin(
>  			goto found_imap;
>  		}
>  
> +		/* no zeroing beyond eof, so split at the boundary */
> +		if (offset_fsb >= eof_fsb)
> +			goto found_imap;
> +		if (offset_fsb < eof_fsb && end_fsb > eof_fsb)
> +			xfs_trim_extent(&imap, offset_fsb, eof_fsb - offset_fsb);
> +
>  		/* COW fork blocks overlap the hole */
>  		xfs_trim_extent(&imap, offset_fsb,
>  			    cmap.br_startoff + cmap.br_blockcount - offset_fsb);
>  		start = XFS_FSB_TO_B(mp, imap.br_startoff);
>  		end = XFS_FSB_TO_B(mp, imap.br_startoff + imap.br_blockcount);
> -		iomap_fill_dirty_folios(iter, &start, end, &iomap_flags);
> +		fbatch_count = iomap_fill_dirty_folios(iter, &start, end,
> +						       &iomap_flags);
>  		xfs_trim_extent(&imap, offset_fsb,
>  				XFS_B_TO_FSB(mp, start) - offset_fsb);
>  
> +		/*
> +		 * Report the COW mapping if we have folios to zero. Otherwise
> +		 * ignore the COW blocks as preallocation and report a hole.
> +		 */
> +		if (fbatch_count) {
> +			xfs_trim_extent(&cmap, imap.br_startoff,
> +					imap.br_blockcount);
> +			imap.br_startoff = end_fsb;	/* fake hole */
> +			goto found_cow;
> +		}
>  		goto found_imap;
>  	}
>  
> @@ -1901,8 +1920,6 @@ xfs_buffered_write_iomap_begin(
>  	 * unwritten extent.
>  	 */
>  	if (flags & IOMAP_ZERO) {
> -		xfs_fileoff_t eof_fsb = XFS_B_TO_FSB(mp, XFS_ISIZE(ip));
> -
>  		if (isnullstartblock(imap.br_startblock) &&
>  		    offset_fsb >= eof_fsb)
>  			goto convert_delay;
> -- 
> 2.52.0
> 
> 

Re: [PATCH v3 8/8] xfs: report cow mappings with dirty pagecache for iomap zero range

[Brian Foster]

On Mon, Mar 09, 2026 at 10:56:02AM -0700, Darrick J. Wong wrote:
> On Mon, Mar 09, 2026 at 09:45:06AM -0400, Brian Foster wrote:
> > XFS has long supported the case where it is possible to have dirty
> > data in pagecache backed by COW fork blocks and a hole in the data
> > fork. This occurs for two reasons. On reflink enabled files, COW
> > fork blocks are allocated with preallocation to help avoid
> > fragmention. Second, if a mapping lookup for a write finds blocks in
> > the COW fork, it consumes those blocks unconditionally. This might
> > mean that COW fork blocks are backed by non-shared blocks or even a
> > hole in the data fork, both of which are perfectly fine.
> > 
> > This leaves an odd corner case for zero range, however, because it
> > needs to distinguish between ranges that are sparse and thus do not
> > require zeroing and those that are not. A range backed by COW fork
> > blocks and a data fork hole might either be a legitimate hole in the
> > file or a range with pending buffered writes that will be written
> > back (which will remap COW fork blocks into the data fork).
> > 
> > This "COW fork blocks over data fork hole" situation has
> > historically been reported as a hole to iomap, which then has grown
> > a flush hack as a workaround to ensure zeroing occurs correctly. Now
> > that this has been lifted into the filesystem and replaced by the
> > dirty folio lookup mechanism, we can do better and use the pagecache
> > state to decide how to report the mapping. If a COW fork range
> > exists with dirty folios in cache, then report a typical shared
> > mapping. If the range is clean in cache, then we can consider the
> > COW blocks preallocation and call it a hole.
> > 
> > This doesn't fundamentally change behavior, but makes mapping
> > reporting more accurate. Note that this does require splitting
> > across the EOF boundary (similar to normal zero range) to ensure we
> > don't spuriously perform post-eof zeroing. iomap will warn about
> > zeroing beyond EOF because folios beyond i_size may not be written
> > back.
> 
> Hrmm.  I wonder if IOMAP_REPORT should grow this new "expose dirty
> unwritten cow fork mappings over a data fork hole" behavior too?  I
> guess the only user of IOMAP_REPORT that might care is swapfile
> activation, but that fsyncs the whole file to disk before starting the
> iteration so I think it won't matter?
> 

I'd have to take a closer look at that and some of the other iomap ops.
I had similar thoughts in the past about whether this might help clean
up seek hole/data and whatnot as well. For here it's primarily just a
cleanup, but IMO it's better for iomap if it doesn't have to carry the
caveat of "is this hole really a hole?"

> > Signed-off-by: Brian Foster <bfoster@redhat.com>
> 
> /me isn't sure he sees the point of doing this only for IOMAP_ZERO but
> you're right that it's weird to pass a folio batch and a hole mapping to
> iomap so
> 
> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
> 

Thanks.

Brian

> --D
> 
> > ---
> >  fs/xfs/xfs_iomap.c | 25 +++++++++++++++++++++----
> >  1 file changed, 21 insertions(+), 4 deletions(-)
> > 
> > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> > index df240931f07a..3bef5ea610bb 100644
> > --- a/fs/xfs/xfs_iomap.c
> > +++ b/fs/xfs/xfs_iomap.c
> > @@ -1786,6 +1786,7 @@ xfs_buffered_write_iomap_begin(
> >  	xfs_fileoff_t		offset_fsb = XFS_B_TO_FSBT(mp, offset);
> >  	xfs_fileoff_t		end_fsb = xfs_iomap_end_fsb(mp, offset, count);
> >  	xfs_fileoff_t		cow_fsb = NULLFILEOFF;
> > +	xfs_fileoff_t		eof_fsb = XFS_B_TO_FSB(mp, XFS_ISIZE(ip));
> >  	struct xfs_bmbt_irec	imap, cmap;
> >  	struct xfs_iext_cursor	icur, ccur;
> >  	xfs_fsblock_t		prealloc_blocks = 0;
> > @@ -1868,7 +1869,8 @@ xfs_buffered_write_iomap_begin(
> >  	 * cache and fill the iomap batch with folios that need zeroing.
> >  	 */
> >  	if ((flags & IOMAP_ZERO) && imap.br_startoff > offset_fsb) {
> > -		loff_t	start, end;
> > +		loff_t		start, end;
> > +		unsigned int	fbatch_count;
> >  
> >  		imap.br_blockcount = imap.br_startoff - offset_fsb;
> >  		imap.br_startoff = offset_fsb;
> > @@ -1883,15 +1885,32 @@ xfs_buffered_write_iomap_begin(
> >  			goto found_imap;
> >  		}
> >  
> > +		/* no zeroing beyond eof, so split at the boundary */
> > +		if (offset_fsb >= eof_fsb)
> > +			goto found_imap;
> > +		if (offset_fsb < eof_fsb && end_fsb > eof_fsb)
> > +			xfs_trim_extent(&imap, offset_fsb, eof_fsb - offset_fsb);
> > +
> >  		/* COW fork blocks overlap the hole */
> >  		xfs_trim_extent(&imap, offset_fsb,
> >  			    cmap.br_startoff + cmap.br_blockcount - offset_fsb);
> >  		start = XFS_FSB_TO_B(mp, imap.br_startoff);
> >  		end = XFS_FSB_TO_B(mp, imap.br_startoff + imap.br_blockcount);
> > -		iomap_fill_dirty_folios(iter, &start, end, &iomap_flags);
> > +		fbatch_count = iomap_fill_dirty_folios(iter, &start, end,
> > +						       &iomap_flags);
> >  		xfs_trim_extent(&imap, offset_fsb,
> >  				XFS_B_TO_FSB(mp, start) - offset_fsb);
> >  
> > +		/*
> > +		 * Report the COW mapping if we have folios to zero. Otherwise
> > +		 * ignore the COW blocks as preallocation and report a hole.
> > +		 */
> > +		if (fbatch_count) {
> > +			xfs_trim_extent(&cmap, imap.br_startoff,
> > +					imap.br_blockcount);
> > +			imap.br_startoff = end_fsb;	/* fake hole */
> > +			goto found_cow;
> > +		}
> >  		goto found_imap;
> >  	}
> >  
> > @@ -1901,8 +1920,6 @@ xfs_buffered_write_iomap_begin(
> >  	 * unwritten extent.
> >  	 */
> >  	if (flags & IOMAP_ZERO) {
> > -		xfs_fileoff_t eof_fsb = XFS_B_TO_FSB(mp, XFS_ISIZE(ip));
> > -
> >  		if (isnullstartblock(imap.br_startblock) &&
> >  		    offset_fsb >= eof_fsb)
> >  			goto convert_delay;
> > -- 
> > 2.52.0
> > 
> > 
> 

Re: [PATCH v3 8/8] xfs: report cow mappings with dirty pagecache for iomap zero range

[Darrick J. Wong]

On Mon, Mar 09, 2026 at 02:31:28PM -0400, Brian Foster wrote:
> On Mon, Mar 09, 2026 at 10:56:02AM -0700, Darrick J. Wong wrote:
> > On Mon, Mar 09, 2026 at 09:45:06AM -0400, Brian Foster wrote:
> > > XFS has long supported the case where it is possible to have dirty
> > > data in pagecache backed by COW fork blocks and a hole in the data
> > > fork. This occurs for two reasons. On reflink enabled files, COW
> > > fork blocks are allocated with preallocation to help avoid
> > > fragmention. Second, if a mapping lookup for a write finds blocks in
> > > the COW fork, it consumes those blocks unconditionally. This might
> > > mean that COW fork blocks are backed by non-shared blocks or even a
> > > hole in the data fork, both of which are perfectly fine.
> > > 
> > > This leaves an odd corner case for zero range, however, because it
> > > needs to distinguish between ranges that are sparse and thus do not
> > > require zeroing and those that are not. A range backed by COW fork
> > > blocks and a data fork hole might either be a legitimate hole in the
> > > file or a range with pending buffered writes that will be written
> > > back (which will remap COW fork blocks into the data fork).
> > > 
> > > This "COW fork blocks over data fork hole" situation has
> > > historically been reported as a hole to iomap, which then has grown
> > > a flush hack as a workaround to ensure zeroing occurs correctly. Now
> > > that this has been lifted into the filesystem and replaced by the
> > > dirty folio lookup mechanism, we can do better and use the pagecache
> > > state to decide how to report the mapping. If a COW fork range
> > > exists with dirty folios in cache, then report a typical shared
> > > mapping. If the range is clean in cache, then we can consider the
> > > COW blocks preallocation and call it a hole.
> > > 
> > > This doesn't fundamentally change behavior, but makes mapping
> > > reporting more accurate. Note that this does require splitting
> > > across the EOF boundary (similar to normal zero range) to ensure we
> > > don't spuriously perform post-eof zeroing. iomap will warn about
> > > zeroing beyond EOF because folios beyond i_size may not be written
> > > back.
> > 
> > Hrmm.  I wonder if IOMAP_REPORT should grow this new "expose dirty
> > unwritten cow fork mappings over a data fork hole" behavior too?  I
> > guess the only user of IOMAP_REPORT that might care is swapfile
> > activation, but that fsyncs the whole file to disk before starting the
> > iteration so I think it won't matter?
> > 
> 
> I'd have to take a closer look at that and some of the other iomap ops.
> I had similar thoughts in the past about whether this might help clean
> up seek hole/data and whatnot as well. For here it's primarily just a
> cleanup, but IMO it's better for iomap if it doesn't have to carry the
> caveat of "is this hole really a hole?"

Ooooh, right -- that does need to get fixed for SEEK_{DATA,HOLE} because
otherwise it'll miss dirty data over a cow preallocation.

> > > Signed-off-by: Brian Foster <bfoster@redhat.com>
> > 
> > /me isn't sure he sees the point of doing this only for IOMAP_ZERO but
> > you're right that it's weird to pass a folio batch and a hole mapping to
> > iomap so
> > 
> > Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
> > 
> 
> Thanks.

NP. :)

--D

> Brian
> 
> > --D
> > 
> > > ---
> > >  fs/xfs/xfs_iomap.c | 25 +++++++++++++++++++++----
> > >  1 file changed, 21 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> > > index df240931f07a..3bef5ea610bb 100644
> > > --- a/fs/xfs/xfs_iomap.c
> > > +++ b/fs/xfs/xfs_iomap.c
> > > @@ -1786,6 +1786,7 @@ xfs_buffered_write_iomap_begin(
> > >  	xfs_fileoff_t		offset_fsb = XFS_B_TO_FSBT(mp, offset);
> > >  	xfs_fileoff_t		end_fsb = xfs_iomap_end_fsb(mp, offset, count);
> > >  	xfs_fileoff_t		cow_fsb = NULLFILEOFF;
> > > +	xfs_fileoff_t		eof_fsb = XFS_B_TO_FSB(mp, XFS_ISIZE(ip));
> > >  	struct xfs_bmbt_irec	imap, cmap;
> > >  	struct xfs_iext_cursor	icur, ccur;
> > >  	xfs_fsblock_t		prealloc_blocks = 0;
> > > @@ -1868,7 +1869,8 @@ xfs_buffered_write_iomap_begin(
> > >  	 * cache and fill the iomap batch with folios that need zeroing.
> > >  	 */
> > >  	if ((flags & IOMAP_ZERO) && imap.br_startoff > offset_fsb) {
> > > -		loff_t	start, end;
> > > +		loff_t		start, end;
> > > +		unsigned int	fbatch_count;
> > >  
> > >  		imap.br_blockcount = imap.br_startoff - offset_fsb;
> > >  		imap.br_startoff = offset_fsb;
> > > @@ -1883,15 +1885,32 @@ xfs_buffered_write_iomap_begin(
> > >  			goto found_imap;
> > >  		}
> > >  
> > > +		/* no zeroing beyond eof, so split at the boundary */
> > > +		if (offset_fsb >= eof_fsb)
> > > +			goto found_imap;
> > > +		if (offset_fsb < eof_fsb && end_fsb > eof_fsb)
> > > +			xfs_trim_extent(&imap, offset_fsb, eof_fsb - offset_fsb);
> > > +
> > >  		/* COW fork blocks overlap the hole */
> > >  		xfs_trim_extent(&imap, offset_fsb,
> > >  			    cmap.br_startoff + cmap.br_blockcount - offset_fsb);
> > >  		start = XFS_FSB_TO_B(mp, imap.br_startoff);
> > >  		end = XFS_FSB_TO_B(mp, imap.br_startoff + imap.br_blockcount);
> > > -		iomap_fill_dirty_folios(iter, &start, end, &iomap_flags);
> > > +		fbatch_count = iomap_fill_dirty_folios(iter, &start, end,
> > > +						       &iomap_flags);
> > >  		xfs_trim_extent(&imap, offset_fsb,
> > >  				XFS_B_TO_FSB(mp, start) - offset_fsb);
> > >  
> > > +		/*
> > > +		 * Report the COW mapping if we have folios to zero. Otherwise
> > > +		 * ignore the COW blocks as preallocation and report a hole.
> > > +		 */
> > > +		if (fbatch_count) {
> > > +			xfs_trim_extent(&cmap, imap.br_startoff,
> > > +					imap.br_blockcount);
> > > +			imap.br_startoff = end_fsb;	/* fake hole */
> > > +			goto found_cow;
> > > +		}
> > >  		goto found_imap;
> > >  	}
> > >  
> > > @@ -1901,8 +1920,6 @@ xfs_buffered_write_iomap_begin(
> > >  	 * unwritten extent.
> > >  	 */
> > >  	if (flags & IOMAP_ZERO) {
> > > -		xfs_fileoff_t eof_fsb = XFS_B_TO_FSB(mp, XFS_ISIZE(ip));
> > > -
> > >  		if (isnullstartblock(imap.br_startblock) &&
> > >  		    offset_fsb >= eof_fsb)
> > >  			goto convert_delay;
> > > -- 
> > > 2.52.0
> > > 
> > > 
> > 
> 
> 

Re: [PATCH v3 8/8] xfs: report cow mappings with dirty pagecache for iomap zero range

[Christoph Hellwig]

On Mon, Mar 09, 2026 at 10:56:02AM -0700, Darrick J. Wong wrote:
> Hrmm.  I wonder if IOMAP_REPORT should grow this new "expose dirty
> unwritten cow fork mappings over a data fork hole" behavior too?  I
> guess the only user of IOMAP_REPORT that might care is swapfile
> activation, but that fsyncs the whole file to disk before starting the
> iteration so I think it won't matter?

swapfile really should not be using IOMAP_REPORT, as IOMAP_REPORT
implies just reporting what is there, while swapfile actually uses
this as an I/O mapping..

Re: [PATCH v3 8/8] xfs: report cow mappings with dirty pagecache for iomap zero range

[Darrick J. Wong]

On Mon, Mar 09, 2026 at 11:50:08PM -0700, Christoph Hellwig wrote:
> On Mon, Mar 09, 2026 at 10:56:02AM -0700, Darrick J. Wong wrote:
> > Hrmm.  I wonder if IOMAP_REPORT should grow this new "expose dirty
> > unwritten cow fork mappings over a data fork hole" behavior too?  I
> > guess the only user of IOMAP_REPORT that might care is swapfile
> > activation, but that fsyncs the whole file to disk before starting the
> > iteration so I think it won't matter?
> 
> swapfile really should not be using IOMAP_REPORT, as IOMAP_REPORT
> implies just reporting what is there, while swapfile actually uses
> this as an I/O mapping..

Swapfiles are really a read-write lease on the entire file's layout,
right?  Maybe we ought to just have an IOMAP_LAYOUT opflag for it and
pnfs?

--D

Re: [PATCH v3 8/8] xfs: report cow mappings with dirty pagecache for iomap zero range

[Christoph Hellwig]

On Tue, Mar 10, 2026 at 07:52:15AM -0700, Darrick J. Wong wrote:
> On Mon, Mar 09, 2026 at 11:50:08PM -0700, Christoph Hellwig wrote:
> > On Mon, Mar 09, 2026 at 10:56:02AM -0700, Darrick J. Wong wrote:
> > > Hrmm.  I wonder if IOMAP_REPORT should grow this new "expose dirty
> > > unwritten cow fork mappings over a data fork hole" behavior too?  I
> > > guess the only user of IOMAP_REPORT that might care is swapfile
> > > activation, but that fsyncs the whole file to disk before starting the
> > > iteration so I think it won't matter?
> > 
> > swapfile really should not be using IOMAP_REPORT, as IOMAP_REPORT
> > implies just reporting what is there, while swapfile actually uses
> > this as an I/O mapping..
> 
> Swapfiles are really a read-write lease on the entire file's layout,
> right?  Maybe we ought to just have an IOMAP_LAYOUT opflag for it and
> pnfs?

I thought about that.  It's basically like a pnfs layout, except that
it can't ever be recalled.

Re: [PATCH v3 8/8] xfs: report cow mappings with dirty pagecache for iomap zero range

[Christoph Hellwig]

On Mon, Mar 09, 2026 at 09:45:06AM -0400, Brian Foster wrote:
> +		if (offset_fsb < eof_fsb && end_fsb > eof_fsb)
> +			xfs_trim_extent(&imap, offset_fsb, eof_fsb - offset_fsb);

overly long line here.

Otherwise this looks good.

Re: [PATCH v3 0/8] iomap, xfs: improve zero range flushing and lookup

[Christoph Hellwig]

On Mon, Mar 09, 2026 at 09:44:58AM -0400, Brian Foster wrote:
> Christoph discovered a regression with zero range in zoned mode on v2 of
> the series. The problem is that the zoned mode iomap_begin() relied on
> the hole mapping flush to handle the case where writes are pending but
> blocks have not yet been mapped into the data fork for the first time.
> Patches 1-2 lift the flush into the begin handler, document the purpose,
> and clean up the logic a bit. They are inserted at the beginning of the
> series to avoid regression from removing the flush from iomap in patch
> 3, but ordering is not critical as zoned support is experimental.

Thanks!  I've run this through my usual zoned testing over last night
and it passes without regression.  I'll also add it to bigger automated
CI, but I expect it to do just fine there as well.