On Wed, May 05, 2021 at 06:12:41PM +0530, Chandan Babu R wrote: > > Hence when doing allocation for the free list, we need to fail the > > allocation rather than block on the only remaining free extent in > > the AG. If we are freeing extents, the AGFL not being full is not an > > issue at all. And if we are allocating extents, the transaction > > reservations should have ensured that the AG had sufficient space in > > it to complete the entire operation without deadlocking waiting for > > space. > > > > Either way, I don't see a problem with making sure the AGFL > > allocations just skip busy extents and fail if the only free extents > > are ones this transaction has freed itself. > > > > Hmm. In the scenario where *all* free extents in the AG were originally freed > by the current transaction (and hence busy in the transaction), How does that happen? > we would need > to be able to recognize this situation and skip invoking > xfs_extent_busy_flush() altogether. If we are freeing extents (i.e XFS_ALLOC_FLAG_FREEING is set) and we are doing allocation for AGFL and we only found busy extents, then it's OK to fail the allocation. We have options here - once we get to the end of the btree and haven't found a candidate that isn't busy, we could fail immediately. Or maybe we try an optimisitic flush which forces the log and waits for as short while (instead of forever) for the generation to change and then fail if we get a timeout response. Or maybe there's a more elegant way of doing this that hasn't yet rattled out of my poor, overloaded brain right now. Just because we currently do a blocking flush doesn't mean we always must do a blocking flush.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
