From: Brian Foster <bfoster@redhat.com>
To: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: [PATCH v4 1/8] xfs: fix iomap hole map reporting for zoned zero range
Date: Wed, 11 Mar 2026 12:24:55 -0400 [thread overview]
Message-ID: <20260311162502.192375-2-bfoster@redhat.com> (raw)
In-Reply-To: <20260311162502.192375-1-bfoster@redhat.com>
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>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
---
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
next prev parent reply other threads:[~2026-03-11 16:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-11 16:24 [PATCH v4 0/8] iomap, xfs: improve zero range flushing and lookup Brian Foster
2026-03-11 16:24 ` Brian Foster [this message]
2026-03-11 16:24 ` [PATCH v4 2/8] xfs: flush dirty pagecache over hole in zoned mode zero range Brian Foster
2026-03-11 22:14 ` Darrick J. Wong
2026-03-11 16:24 ` [PATCH v4 3/8] iomap, xfs: lift zero range hole mapping flush into xfs Brian Foster
2026-03-11 16:24 ` [PATCH v4 4/8] xfs: flush eof folio before insert range size update Brian Foster
2026-03-11 21:36 ` Darrick J. Wong
2026-03-11 16:24 ` [PATCH v4 5/8] xfs: look up cow fork extent earlier for buffered iomap_begin Brian Foster
2026-03-11 16:25 ` [PATCH v4 6/8] xfs: only flush when COW fork blocks overlap data fork holes Brian Foster
2026-03-11 16:25 ` [PATCH v4 7/8] xfs: replace zero range flush with folio batch Brian Foster
2026-03-11 16:25 ` [PATCH v4 8/8] xfs: report cow mappings with dirty pagecache for iomap zero range Brian Foster
2026-03-12 6:55 ` Christoph Hellwig
2026-03-18 9:13 ` [PATCH v4 0/8] iomap, xfs: improve zero range flushing and lookup Carlos Maiolino
2026-03-18 9:40 ` Christian Brauner
2026-03-23 10:47 ` Carlos Maiolino
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=20260311162502.192375-2-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