From: Brian Foster <bfoster@redhat.com>
To: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: [PATCH v2 3/5] xfs: look up cow fork extent earlier for buffered iomap_begin
Date: Thu, 29 Jan 2026 10:50:26 -0500 [thread overview]
Message-ID: <20260129155028.141110-4-bfoster@redhat.com> (raw)
In-Reply-To: <20260129155028.141110-1-bfoster@redhat.com>
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>
---
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 896d0dd07613..0edab7af4a10 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -1809,14 +1809,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) {
@@ -1883,24 +1898,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
next prev parent reply other threads:[~2026-01-29 15:50 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-29 15:50 [PATCH v2 0/5] iomap, xfs: improve zero range flushing and lookup Brian Foster
2026-01-29 15:50 ` [PATCH v2 1/5] iomap, xfs: lift zero range hole mapping flush into xfs Brian Foster
2026-02-10 16:15 ` Christoph Hellwig
2026-02-10 19:14 ` Brian Foster
2026-02-11 15:36 ` Christoph Hellwig
2026-02-13 6:06 ` Christoph Hellwig
2026-02-13 17:37 ` Brian Foster
2026-03-02 19:02 ` Brian Foster
2026-03-03 14:37 ` Christoph Hellwig
2026-03-03 19:00 ` Brian Foster
2026-03-04 13:13 ` Christoph Hellwig
2026-03-04 14:17 ` Brian Foster
2026-03-04 14:41 ` Christoph Hellwig
2026-03-04 15:02 ` Brian Foster
2026-03-04 17:04 ` Brian Foster
2026-03-05 14:11 ` Christoph Hellwig
2026-03-05 15:06 ` Brian Foster
2026-03-05 16:10 ` Christoph Hellwig
2026-02-13 10:20 ` Nirjhar Roy (IBM)
2026-02-13 16:24 ` Darrick J. Wong
2026-02-18 17:41 ` Nirjhar Roy (IBM)
2026-01-29 15:50 ` [PATCH v2 2/5] xfs: flush eof folio before insert range size update Brian Foster
2026-02-10 16:16 ` Christoph Hellwig
2026-02-10 19:14 ` Brian Foster
2026-01-29 15:50 ` Brian Foster [this message]
2026-02-10 16:17 ` [PATCH v2 3/5] xfs: look up cow fork extent earlier for buffered iomap_begin Christoph Hellwig
2026-01-29 15:50 ` [PATCH v2 4/5] xfs: only flush when COW fork blocks overlap data fork holes Brian Foster
2026-02-10 16:19 ` Christoph Hellwig
2026-02-10 19:18 ` Brian Foster
2026-02-17 15:06 ` Nirjhar Roy (IBM)
2026-02-18 15:37 ` Brian Foster
2026-02-18 17:40 ` Nirjhar Roy (IBM)
2026-01-29 15:50 ` [PATCH v2 5/5] xfs: replace zero range flush with folio batch Brian Foster
2026-02-10 16:21 ` Christoph Hellwig
2026-02-10 19:19 ` Brian Foster
2026-02-11 15:41 ` 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=20260129155028.141110-4-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.