summaryrefslogtreecommitdiffstats
path: root/fs/xfs/xfs_rtalloc.c
diff options
context:
space:
mode:
authorDarrick J. Wong <djwong@kernel.org>2022-11-30 09:25:51 -0800
committerDarrick J. Wong <djwong@kernel.org>2022-12-01 09:32:04 -0800
commitb25d1984aa884fc91a73a5a407b9ac976d441e9b (patch)
tree352044d6054fa773d7bdfe1b8dbfc6f1df3a7aaf /fs/xfs/xfs_rtalloc.c
parent9d720a5a658f5135861773f26e927449bef93d61 (diff)
downloadlinux-b25d1984aa884fc91a73a5a407b9ac976d441e9b.tar.bz2
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>
Diffstat (limited to 'fs/xfs/xfs_rtalloc.c')
0 files changed, 0 insertions, 0 deletions