From: "Darrick J. Wong" <djwong@kernel.org>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 4/6] xfs: look up cow fork extent earlier for buffered iomap_begin
Date: Wed, 5 Nov 2025 14:26:07 -0800 [thread overview]
Message-ID: <20251105222607.GH196370@frogsfrogsfrogs> (raw)
In-Reply-To: <20251016190303.53881-5-bfoster@redhat.com>
On Thu, Oct 16, 2025 at 03:03:01PM -0400, Brian Foster wrote:
> 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>
Looks fine to me,
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
--D
> ---
> 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 b84c94558cc9..ba5697d8b8fd 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -1753,14 +1753,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) {
> @@ -1827,24 +1842,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.51.0
>
>
next prev parent reply other threads:[~2025-11-05 22:26 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-16 19:02 [PATCH 0/6] iomap, xfs: improve zero range flushing and lookup Brian Foster
2025-10-16 19:02 ` [PATCH 1/6] iomap: replace folio_batch allocation with stack allocation Brian Foster
2025-11-05 0:07 ` Darrick J. Wong
2025-11-05 15:27 ` Brian Foster
2025-11-05 21:41 ` Darrick J. Wong
2025-11-06 15:51 ` Brian Foster
2025-11-06 15:58 ` Darrick J. Wong
2025-10-16 19:02 ` [PATCH 2/6] iomap, xfs: lift zero range hole mapping flush into xfs Brian Foster
2025-11-05 0:31 ` Darrick J. Wong
2025-11-05 15:33 ` Brian Foster
2025-11-05 22:23 ` Darrick J. Wong
2025-11-06 15:52 ` Brian Foster
2025-11-06 23:32 ` Darrick J. Wong
2025-11-07 13:52 ` Brian Foster
2025-11-07 13:59 ` Christoph Hellwig
2025-11-07 13:57 ` Christoph Hellwig
2025-11-07 13:55 ` Christoph Hellwig
2025-10-16 19:03 ` [PATCH 3/6] xfs: flush eof folio before insert range size update Brian Foster
2025-11-05 0:14 ` Darrick J. Wong
2025-11-05 15:34 ` Brian Foster
2025-11-05 22:15 ` Darrick J. Wong
2025-11-18 20:08 ` Brian Foster
2025-10-16 19:03 ` [PATCH 4/6] xfs: look up cow fork extent earlier for buffered iomap_begin Brian Foster
2025-11-05 22:26 ` Darrick J. Wong [this message]
2025-10-16 19:03 ` [PATCH 5/6] xfs: only flush when COW fork blocks overlap data fork holes Brian Foster
2025-10-16 19:03 ` [PATCH 6/6] xfs: replace zero range flush with folio batch Brian Foster
2025-11-05 22:37 ` Darrick J. Wong
2025-11-06 15:53 ` Brian Foster
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=20251105222607.GH196370@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=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.