On Wed, Jan 27, 2021 at 10:02:01PM -0800, Darrick J. Wong wrote:

From: Darrick J. Wong <djwong@kernel.org>

Now that we've converted xfs_reflink_remap_extent to use the new
xfs_trans_alloc_inode API, we can focus on its slightly unusual behavior
with regard to quota reservations.

Since it's valid to remap written blocks into a hole, we must be able to
increase the quota count by the number of blocks in the mapping.
However, the incore space reservation process requires us to supply an
asymptotic guess before we can gain exclusive access to resources.  We'd
like to reserve all the quota we need up front, but we also don't want
to fail a written -> allocated remap operation unnecessarily.

The solution is to make the remap_extents function call the transaction
allocation function twice.  The first time we ask to reserve enough
space and quota to handle the absolute worst case situation, but if that
fails, we can fall back to the old strategy: ask for the bare minimum
space reservation upfront and increase the quota reservation later if we
need to.

This isn't a problem now, but in the next patchset we change the
transaction and quota code to try to reclaim space if we cannot reserve
free space or quota.  Restructuring the remap_extent function in this
manner means that if the fallback increase fails, we can pass that back
to the caller knowing that the transaction allocation already tried
freeing space.

The patch itself looks good, but I don't see what problem it solves.

Maybe I'll find out when reading the remaining patches..