Re: [PATCH 5.4 V2] xfs: redesign the reflink remap loop to fix blkres depletion crash

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Nov 21, 2022 at 03:25:06PM +0530, Chandan Babu R wrote:
> From: "Darrick J. Wong" <darrick.wong@oracle.com>
> 
> commit 00fd1d56dd08a8ceaa9e4ee1a41fefd9f6c6bc7d upstream.
> 
> 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>
> [backported to 5.4.y - Tested-by above does not refer to the backport]
> Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
> Acked-by: Darrick J. Wong <djwong@kernel.org>
> ---
> Changelog:
> V1 -> V2:
>    1. Add a note in the commit message to indicate that the Tested-by
>       tag from the original commit is not applicable to the backport.

Text now updated, thanks.