Re: [PATCH 1/3] xfs: simplify extent allocation alignment

Dave Chinner
2024-04-02T21:26:34Z

On Tue, Apr 02, 2024 at 04:11:20PM +0100, John Garry wrote:
> On 02/04/2024 08:49, John Garry wrote:
> > Update:
> > So I have some more patches from trying to support both truncate and
> > fallocate + punch/insert/collapse for forcealign.
> >
> > I seem to have at least 2x problems:
> > - unexpected -ENOSPC in some case
>
> This -ENOSPC seems related to xfs_bmap_select_minlen() again.
>
> I find that it occurs when calling xfs_bmap_select_minlen() and blen ==
> maxlen again, like:
> blen=64 args->alignment=16, minlen=0, maxlen=64
>
> And then this gives:
> args->minlen=48 blen=64

Which is perfectly reasonable - it fits the bounds specified just
fine, and we'll get a 64 block allocation if that free space is
exactly aligned. Otherwise we'll get a 48 block allocation.

> But xfs_alloc_vextent_start_ag() -> xfs_alloc_vextent_iterate_ags() does not
> seem to find something suitable.

Entirely possible. The AGFL might have needed refilling, so there
really wasn't enough blocks remaining for an aligned allocation to
take place after doing that. That's a real ENOSPC condition, despite
the best length sampling indicating that the allocation could be
done.

Remember, bestlen sampling is racy - it does not hold the AGF
locked from the point of sampling to the point of allocation. Hence
when we finally go to do the allocation after setting it all up, we
might have raced with another allocation that took the free space
sampled during the bestlen pass and so then the allocation fails
despite the setup saying it should succeed.

Fundamentally, if the filesystem's best free space length is the
same size as the requested allocation, *failure is expected* and the
fallback attempts progressively remove restrictions (such as
alignment) to allow sub-optimal extents to be allocated down to
minlen in size. Forced alignment turns off these fallbacks, so you
are going to see hard ENOSPC errors the moment the filesystem runs
out of contiguous free space extents large enough to hold aligned
allocations.

This can happen a -long- way away from a real enospc condition -
depending on alignment constraints, you can start seeing this sort
of behaviour (IIRC my math correctly) at around 70% full. The larger
the alignment and the older the filesystem, the earlier this sort of
ENOSPC event will occur.

Use `xfs_spaceman -c 'freesp'` to dump the free space extent size
histogram. That will quickly tell you if there is no remaining free
extents large enough for an aligned 48 block allocation to succeed.
With an alignment of 16 blocks, this requires at least a 63 block
free space extent to succeed.

IOWs, we should expect ENOSPC to occur long before the filesystem
reports that it is out of space when we are doing forced alignment
allocation.

-Dave.
--
Dave Chinner
david@fromorbit.com