]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commit
xfs_repair: correctly account for free space btree shrinks when fixing freelist
authorDarrick J. Wong <darrick.wong@oracle.com>
Fri, 26 Apr 2019 20:41:59 +0000 (15:41 -0500)
committerEric Sandeen <sandeen@redhat.com>
Fri, 26 Apr 2019 20:41:59 +0000 (15:41 -0500)
commit1cdc777df735ca45f9b3aeb35613a06669b5c641
tree8ae1e20e45cb7674cc04de77fc9d5d3ffe6ab8ba
parentbbb437453182d179002f33a9a10f791514ade832
xfs_repair: correctly account for free space btree shrinks when fixing freelist

When we fix the freelist at the end of build_agf_agfl in phase 5 of
repair, we need to create incore rmap records for the blocks that get
added to the AGFL.  We can't let the regular freelist fixing code use
the regular on-disk rmapbt update code because the rmapbt isn't fully
set up yet.

Unfortunately, the original code fails to account for the fact that the
free space btrees can shrink when we allocate blocks to fix the
freelist; those blocks are also put on the freelist, but there are
already incore rmaps for all the free space btree blocks.  We must not
create (redundant) incore rmaps for those blocks.  If we do, repair
fails with a complaint that rebuilding the rmapbt failed during phase 5.
xfs/137 on a 1k block size occasionally triggers this bug.

To fix the problem, construct a bitmap of all OWN_AG blocks that we know
about before traversing the AGFL, and only create new incore rmaps for
those AGFL blocks that are not already tracked in the bitmap.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Bill O'Donnell <billodo@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
repair/rmap.c