]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commit
xfs_repair: check for global free space concerns with default btree slack levels
authorDarrick J. Wong <djwong@kernel.org>
Mon, 24 Feb 2025 18:22:01 +0000 (10:22 -0800)
committerDarrick J. Wong <djwong@kernel.org>
Tue, 25 Feb 2025 17:16:01 +0000 (09:16 -0800)
commite3429101cdbd54bcee79c6cb26a17f9ee13d1e70
tree7b18f758a2c370c27517b92fd931b19c94a308f5
parentd8ad5e2dfcea4b1539ab48cc6b3e3e0533343e56
xfs_repair: check for global free space concerns with default btree slack levels

It's possible that before repair was started, the filesystem might have
been nearly full, and its metadata btree blocks could all have been
nearly full.  If we then rebuild the btrees with blocks that are only
75% full, that expansion might be enough to run out of free space.  The
solution to this is to pack the new blocks completely full if we fear
running out of space.

Previously, we only had to check and decide that on a per-AG basis.
However, now that XFS can have filesystems with metadata btrees rooted
in inodes, we have a global free space concern because there might be
enough space in each AG to regenerate the AG btrees at 75%, but that
might not leave enough space to regenerate the inode btrees, even if we
fill those blocks to 100%.

Hence we need to precompute the worst case space usage for all btrees in
the filesystem and compare /that/ against the global free space to
decide if we're going to pack the btrees maximally to conserve space.
That decision can override the per-AG determination.

Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
repair/globals.c
repair/globals.h
repair/phase5.c
repair/phase6.c