On Wed, Jan 27, 2021 at 10:02:01PM -0800, Darrick J. Wong wrote: > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > 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..
