From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
patches@lists.linux.dev, xfs-stable@lists.linux.dev,
Darrick Wong <djwong@kernel.org>,
Brian Foster <bfoster@redhat.com>,
Carlos Maiolino <cem@kernel.org>,
Catherine Hoang <catherine.hoang@oracle.com>
Subject: [PATCH 6.6 006/140] xfs: skip background cowblock trims on inodes open for write
Date: Mon, 24 Feb 2025 15:33:25 +0100 [thread overview]
Message-ID: <20250224142603.256386231@linuxfoundation.org> (raw)
In-Reply-To: <20250224142602.998423469@linuxfoundation.org>
6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brian Foster <bfoster@redhat.com>
commit 90a71daaf73f5d39bb0cbb3c7ab6af942fe6233e upstream.
The background blockgc scanner runs on a 5m interval by default and
trims preallocation (post-eof and cow fork) from inodes that are
otherwise idle. Idle effectively means that iolock can be acquired
without blocking and that the inode has no dirty pagecache or I/O in
flight.
This simple mechanism and heuristic has worked fairly well for
post-eof speculative preallocations. Support for reflink and COW
fork preallocations came sometime later and plugged into the same
mechanism, with similar heuristics. Some recent testing has shown
that COW fork preallocation may be notably more sensitive to blockgc
processing than post-eof preallocation, however.
For example, consider an 8GB reflinked file with a COW extent size
hint of 1MB. A worst case fully randomized overwrite of this file
results in ~8k extents of an average size of ~1MB. If the same
workload is interrupted a couple times for blockgc processing
(assuming the file goes idle), the resulting extent count explodes
to over 100k extents with an average size <100kB. This is
significantly worse than ideal and essentially defeats the COW
extent size hint mechanism.
While this particular test is instrumented, it reflects a fairly
reasonable pattern in practice where random I/Os might spread out
over a large period of time with varying periods of (in)activity.
For example, consider a cloned disk image file for a VM or container
with long uptime and variable and bursty usage. A background blockgc
scan that races and processes the image file when it happens to be
clean and idle can have a significant effect on the future
fragmentation level of the file, even when still in use.
To help combat this, update the heuristic to skip cowblocks inodes
that are currently opened for write access during non-sync blockgc
scans. This allows COW fork preallocations to persist for as long as
possible unless otherwise needed for functional purposes (i.e. a
sync scan), the file is idle and closed, or the inode is being
evicted from cache. While here, update the comments to help
distinguish performance oriented heuristics from the logic that
exists to maintain functional correctness.
Suggested-by: Darrick Wong <djwong@kernel.org>
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/xfs/xfs_icache.c | 31 +++++++++++++++++++++++--------
1 file changed, 23 insertions(+), 8 deletions(-)
--- a/fs/xfs/xfs_icache.c
+++ b/fs/xfs/xfs_icache.c
@@ -1234,14 +1234,17 @@ xfs_inode_clear_eofblocks_tag(
}
/*
- * Set ourselves up to free CoW blocks from this file. If it's already clean
- * then we can bail out quickly, but otherwise we must back off if the file
- * is undergoing some kind of write.
+ * Prepare to free COW fork blocks from an inode.
*/
static bool
xfs_prep_free_cowblocks(
- struct xfs_inode *ip)
+ struct xfs_inode *ip,
+ struct xfs_icwalk *icw)
{
+ bool sync;
+
+ sync = icw && (icw->icw_flags & XFS_ICWALK_FLAG_SYNC);
+
/*
* Just clear the tag if we have an empty cow fork or none at all. It's
* possible the inode was fully unshared since it was originally tagged.
@@ -1253,9 +1256,21 @@ xfs_prep_free_cowblocks(
}
/*
- * If the mapping is dirty or under writeback we cannot touch the
- * CoW fork. Leave it alone if we're in the midst of a directio.
+ * A cowblocks trim of an inode can have a significant effect on
+ * fragmentation even when a reasonable COW extent size hint is set.
+ * Therefore, we prefer to not process cowblocks unless they are clean
+ * and idle. We can never process a cowblocks inode that is dirty or has
+ * in-flight I/O under any circumstances, because outstanding writeback
+ * or dio expects targeted COW fork blocks exist through write
+ * completion where they can be remapped into the data fork.
+ *
+ * Therefore, the heuristic used here is to never process inodes
+ * currently opened for write from background (i.e. non-sync) scans. For
+ * sync scans, use the pagecache/dio state of the inode to ensure we
+ * never free COW fork blocks out from under pending I/O.
*/
+ if (!sync && inode_is_open_for_write(VFS_I(ip)))
+ return false;
if ((VFS_I(ip)->i_state & I_DIRTY_PAGES) ||
mapping_tagged(VFS_I(ip)->i_mapping, PAGECACHE_TAG_DIRTY) ||
mapping_tagged(VFS_I(ip)->i_mapping, PAGECACHE_TAG_WRITEBACK) ||
@@ -1291,7 +1306,7 @@ xfs_inode_free_cowblocks(
if (!xfs_iflags_test(ip, XFS_ICOWBLOCKS))
return 0;
- if (!xfs_prep_free_cowblocks(ip))
+ if (!xfs_prep_free_cowblocks(ip, icw))
return 0;
if (!xfs_icwalk_match(ip, icw))
@@ -1320,7 +1335,7 @@ xfs_inode_free_cowblocks(
* Check again, nobody else should be able to dirty blocks or change
* the reflink iflag now that we have the first two locks held.
*/
- if (xfs_prep_free_cowblocks(ip))
+ if (xfs_prep_free_cowblocks(ip, icw))
ret = xfs_reflink_cancel_cow_range(ip, 0, NULLFILEOFF, false);
return ret;
}
next prev parent reply other threads:[~2025-02-24 14:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250224142602.998423469@linuxfoundation.org>
2025-02-24 14:33 ` [PATCH 6.6 002/140] xfs: assert a valid limit in xfs_rtfind_forw Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 003/140] xfs: validate inumber in xfs_iget Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 004/140] xfs: fix a sloppy memory handling bug in xfs_iroot_realloc Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 005/140] xfs: fix a typo Greg Kroah-Hartman
2025-02-24 14:33 ` Greg Kroah-Hartman [this message]
2025-02-24 14:33 ` [PATCH 6.6 007/140] xfs: dont free cowblocks from under dirty pagecache on unshare Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 008/140] xfs: merge xfs_attr_leaf_try_add into xfs_attr_leaf_addname Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 009/140] xfs: return bool from xfs_attr3_leaf_add Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 010/140] xfs: distinguish extra split from real ENOSPC from xfs_attr3_leaf_split Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 011/140] xfs: distinguish extra split from real ENOSPC from xfs_attr_node_try_addname Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 012/140] xfs: fold xfs_bmap_alloc_userdata into xfs_bmapi_allocate Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 013/140] xfs: dont ifdef around the exact minlen allocations Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 014/140] xfs: call xfs_bmap_exact_minlen_extent_alloc from xfs_bmap_btalloc Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 015/140] xfs: support lowmode allocations in xfs_bmap_exact_minlen_extent_alloc Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 016/140] xfs: Use try_cmpxchg() in xlog_cil_insert_pcp_aggregate() Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 017/140] xfs: Remove empty declartion in header file Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 018/140] xfs: pass the exact range to initialize to xfs_initialize_perag Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 019/140] xfs: update the file system geometry after recoverying superblock buffers Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 020/140] xfs: error out when a superblock buffer update reduces the agcount Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 021/140] xfs: dont use __GFP_RETRY_MAYFAIL in xfs_initialize_perag Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 022/140] xfs: update the pag for the last AG at recovery time Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 023/140] xfs: Reduce unnecessary searches when searching for the best extents Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 024/140] xfs: streamline xfs_filestream_pick_ag Greg Kroah-Hartman
2025-02-24 14:33 ` [PATCH 6.6 025/140] xfs: Check for delayed allocations before setting extsize Greg Kroah-Hartman
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=20250224142603.256386231@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=bfoster@redhat.com \
--cc=catherine.hoang@oracle.com \
--cc=cem@kernel.org \
--cc=djwong@kernel.org \
--cc=patches@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=xfs-stable@lists.linux.dev \
/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