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 7/8] xfs: replace zero range flush with folio batch
Date: Mon,  9 Mar 2026 09:45:05 -0400	[thread overview]
Message-ID: <20260309134506.167663-8-bfoster@redhat.com> (raw)
In-Reply-To: <20260309134506.167663-1-bfoster@redhat.com>

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


  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 ` [PATCH v3 2/8] xfs: flush dirty pagecache over hole in zoned mode " Brian Foster
2026-03-09 17:22   ` 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 ` Brian Foster [this message]
2026-03-09 17:48   ` [PATCH v3 7/8] xfs: replace zero range flush with folio batch 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-8-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