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:
- 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.