]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commit
xfs: redesign the reflink remap loop to fix blkres depletion crash
authorDarrick J. Wong <darrick.wong@oracle.com>
Fri, 4 Sep 2020 19:54:20 +0000 (15:54 -0400)
committerEric Sandeen <sandeen@sandeen.net>
Fri, 4 Sep 2020 19:54:20 +0000 (15:54 -0400)
commit9ff3a1a7dfd58735c871dc00eaaac8fe6a23b086
tree2b4dbd3cf8bc1e84d2870966827c6851354ac985
parent23571db900f1f0172c7dea12f794450ec48b133f
xfs: redesign the reflink remap loop to fix blkres depletion crash

Source kernel commit: 00fd1d56dd08a8ceaa9e4ee1a41fefd9f6c6bc7d

The existing reflink remapping loop has some structural problems that
need addressing:

The biggest problem is that we create one transaction for each extent in
the source file without accounting for the number of mappings there are
for the same range in the destination file.  In other words, we don't
know the number of remap operations that will be necessary and we
therefore cannot guess the block reservation required.  On highly
fragmented filesystems (e.g. ones with active dedupe) we guess wrong,
run out of block reservation, and fail.

The second problem is that we don't actually use the bmap intents to
their full potential -- instead of calling bunmapi directly and having
to deal with its backwards operation, we could call the deferred ops
xfs_bmap_unmap_extent and xfs_refcount_decrease_extent instead.  This
makes the frontend loop much simpler.

Solve all of these problems by refactoring the remapping loops so that
we only perform one remapping operation per transaction, and each
operation only tries to remap a single extent from source to dest.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reported-by: Edwin Török <edwin@etorok.net>
Tested-by: Edwin Török <edwin@etorok.net>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
libxfs/xfs_bmap.h