Hi all,
A few months ago, the multi-fsblock untorn writes patchset added a bunch of log intent item helper functions to estimate the number of intent items that could be added to a particular transaction. Those helpers enabled us to compute a safe upper bound on the number of blocks that could be written in an untorn fashion with filesystem-provided out of place writes.
Currently, the online fsck code employs static limits on the number of intent items that it's willing to accrue to a single transaction when it's trying to reap what it thinks are the old blocks from a corrupt structure. There have been no problems reported with this approach after years of testing, but static limits are scary and gross because overestimating the intent item limit could result in transaction overflows and dead filesystems; and underestimating causes unnecessary overhead.
This series uses the new log intent item size helpers to estimate the limits dynamically based on worst-case per-block repair work vs. the size of the scrub transaction. After several months of testing this, there don't seem to be any problems here either.
If you're going to start using this code, I strongly recommend pulling from my git trees, which are linked below.
This has been running on the djcloud for months with no problems. Enjoy! Comments and questions are, as always, welcome.
--D
kernel git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=fix... --- Commits in this patchset: * xfs: prepare reaping code for dynamic limits * xfs: convert the ifork reap code to use xreap_state * xfs: use deferred intent items for reaping crosslinked blocks * xfs: compute per-AG extent reap limits dynamically * xfs: compute data device CoW staging extent reap limits dynamically * xfs: compute realtime device CoW staging extent reap limits dynamically * xfs: compute file mapping reap limits dynamically * xfs: remove static reap limits * xfs: use deferred reaping for data device cow extents --- fs/xfs/scrub/repair.h | 8 - fs/xfs/scrub/trace.h | 45 ++++ fs/xfs/scrub/newbt.c | 7 + fs/xfs/scrub/reap.c | 622 +++++++++++++++++++++++++++++++++++++++---------- fs/xfs/scrub/trace.c | 1 5 files changed, 552 insertions(+), 131 deletions(-)
From: Darrick J. Wong djwong@kernel.org
When we're removing rmap records for crosslinked blocks, use deferred intent items so that we can try to free/unmap as many of the old data structure's blocks as we can in the same transaction as the commit.
Cc: stable@vger.kernel.org # v6.6 Fixes: 1c7ce115e52106 ("xfs: reap large AG metadata extents when possible") Signed-off-by: "Darrick J. Wong" djwong@kernel.org --- fs/xfs/scrub/reap.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/xfs/scrub/reap.c b/fs/xfs/scrub/reap.c index db46f6cd4112f3..33272729249f64 100644 --- a/fs/xfs/scrub/reap.c +++ b/fs/xfs/scrub/reap.c @@ -430,8 +430,6 @@ xreap_agextent_iter( trace_xreap_dispose_unmap_extent(pag_group(sc->sa.pag), agbno, *aglenp);
- xreap_force_defer_finish(rs); - if (rs->oinfo == &XFS_RMAP_OINFO_COW) { /* * If we're unmapping CoW staging extents, remove the @@ -440,11 +438,14 @@ xreap_agextent_iter( */ xfs_refcount_free_cow_extent(sc->tp, false, fsbno, *aglenp); + xreap_force_defer_finish(rs); return 0; }
- return xfs_rmap_free(sc->tp, sc->sa.agf_bp, sc->sa.pag, agbno, - *aglenp, rs->oinfo); + xfs_rmap_free_extent(sc->tp, false, fsbno, *aglenp, + rs->oinfo->oi_owner); + xreap_inc_defer(rs); + return 0; }
trace_xreap_dispose_free_extent(pag_group(sc->sa.pag), agbno, *aglenp);
On Thu, Aug 28, 2025 at 07:28:38AM -0700, Darrick J. Wong wrote:
From: Darrick J. Wong djwong@kernel.org
When we're removing rmap records for crosslinked blocks, use deferred intent items so that we can try to free/unmap as many of the old data structure's blocks as we can in the same transaction as the commit.
Shouldn't this be at the start of the series?
Otherwise looks good:
Reviewed-by: Christoph Hellwig hch@lst.de
On Tue, Sep 02, 2025 at 08:25:45AM +0200, Christoph Hellwig wrote:
On Thu, Aug 28, 2025 at 07:28:38AM -0700, Darrick J. Wong wrote:
From: Darrick J. Wong djwong@kernel.org
When we're removing rmap records for crosslinked blocks, use deferred intent items so that we can try to free/unmap as many of the old data structure's blocks as we can in the same transaction as the commit.
Shouldn't this be at the start of the series?
Yeah, will move it.
Otherwise looks good:
Reviewed-by: Christoph Hellwig hch@lst.de
Thanks!
--D
linux-stable-mirror@lists.linaro.org
-
Christoph Hellwig -
Darrick J. Wong