public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: [PATCH v3 2/8] xfs: flush dirty pagecache over hole in zoned mode zero range
Date: Mon,  9 Mar 2026 09:45:00 -0400	[thread overview]
Message-ID: <20260309134506.167663-3-bfoster@redhat.com> (raw)
In-Reply-To: <20260309134506.167663-1-bfoster@redhat.com>

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


  parent reply	other threads:[~2026-03-09 13:45 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09 13:44 [PATCH v3 0/8] iomap, xfs: improve zero range flushing and lookup Brian Foster
2026-03-09 13:44 ` [PATCH v3 1/8] xfs: fix iomap hole map reporting for zoned zero range Brian Foster
2026-03-09 17:11   ` Darrick J. Wong
2026-03-09 18:18     ` Brian Foster
2026-03-10 14:47       ` Darrick J. Wong
2026-03-10  6:45   ` Christoph Hellwig
2026-03-09 13:45 ` Brian Foster [this message]
2026-03-09 17:22   ` [PATCH v3 2/8] xfs: flush dirty pagecache over hole in zoned mode " Darrick J. Wong
2026-03-09 18:19     ` Brian Foster
2026-03-10  6:47     ` Christoph Hellwig
2026-03-10 14:48       ` Darrick J. Wong
2026-03-10  6:45   ` Christoph Hellwig
2026-03-09 13:45 ` [PATCH v3 3/8] iomap, xfs: lift zero range hole mapping flush into xfs Brian Foster
2026-03-09 17:40   ` Darrick J. Wong
2026-03-10  6:47   ` Christoph Hellwig
2026-03-09 13:45 ` [PATCH v3 4/8] xfs: flush eof folio before insert range size update Brian Foster
2026-03-09 17:32   ` Darrick J. Wong
2026-03-09 18:24     ` Brian Foster
2026-03-09 13:45 ` [PATCH v3 5/8] xfs: look up cow fork extent earlier for buffered iomap_begin Brian Foster
2026-03-09 13:45 ` [PATCH v3 6/8] xfs: only flush when COW fork blocks overlap data fork holes Brian Foster
2026-03-09 17:47   ` Darrick J. Wong
2026-03-09 13:45 ` [PATCH v3 7/8] xfs: replace zero range flush with folio batch Brian Foster
2026-03-09 17:48   ` Darrick J. Wong
2026-03-09 13:45 ` [PATCH v3 8/8] xfs: report cow mappings with dirty pagecache for iomap zero range Brian Foster
2026-03-09 17:56   ` Darrick J. Wong
2026-03-09 18:31     ` Brian Foster
2026-03-09 18:38       ` Darrick J. Wong
2026-03-10  6:50     ` Christoph Hellwig
2026-03-10 14:52       ` Darrick J. Wong
2026-03-10 14:59         ` Christoph Hellwig
2026-03-10  6:49   ` Christoph Hellwig
2026-03-10  6:45 ` [PATCH v3 0/8] iomap, xfs: improve zero range flushing and lookup Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260309134506.167663-3-bfoster@redhat.com \
    --to=bfoster@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox