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@xxxxxxxxxxxxx
