Skip to content

xfs: estimate post-merge refcounts correctly

Bill O'Donnell requested to merge bodonnel/centos-stream-9:bz2161676 into main

xfs: estimate post-merge refcounts correctly

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2161676

xfs/179 fails after it was recently modified for reproducing a bug regarding refcount overflowing: https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/commit/?h=for-next&id=56c8f841407c29808d370d06929a3f58c7afeee3

fixed by: 9d720a5a658f: xfs: hoist refcount record merge predicates b25d1984aa88: xfs: estimate post-merge refcounts correctly

commit b25d1984aa884fc91a73a5a407b9ac976d441e9b Author: Darrick J. Wong djwong@kernel.org Date: Wed Nov 30 09:25:51 2022 -0800

xfs: estimate post-merge refcounts correctly

Upon enabling fsdax + reflink for XFS, xfs/179 began to report refcount
metadata corruptions after being run.  Specifically, xfs_repair noticed
single-block refcount records that could be combined but had not been.

The root cause of this is improper MAXREFCOUNT edge case handling in
xfs_refcount_merge_extents.  When we're trying to find candidates for a
refcount btree record merge, we compute the refcount attribute of the
merged record, but we fail to account for the fact that once a record
hits rc_refcount == MAXREFCOUNT, it is pinned that way forever.  Hence
the computed refcount is wrong, and we fail to merge the extents.
Fix this by adjusting the merge predicates to compute the adjusted
refcount correctly.

Fixes: 3172725814f9 ("xfs: adjust refcount of an extent of blocks in refcount btree")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Xiao Yang <yangx.jy@fujitsu.com>

Signed-off-by: Bill O'Donnell bodonnel@redhat.com

Edited by Bill O'Donnell

Merge request reports