Re: [PATCH 0/5] xfs: allocation alignment for forced alignment

[John Garry <john.g.garry@oracle.com>]

On 03/04/2024 00:28, Dave Chinner wrote:

Hi Dave,

Can we come up with some merging strategy here?

This feature is blocking me sending an updated version of my XFS support 
for block atomic writes series.

I suppose we can transfer all the other FORCEALIGN patches from that 
series into this one, so that this series is a fully complete feature 
which could be merged separately.

Thanks,
John

> This patchset prepares the allocator infrastructure for extent size
> hint alignment to guarantee alignment of extents rather than just be
> a hint.
> 
> Extent alignment is currently driven by multiple variables that come
> from different sources and are applied at different times. Stripe
> alignment currently defines the extent start alignment, whilst
> extent size hints only affect the extent length and not the start
> alignment.  There are also assumptions about alignment of allocation
> parameters (such as the maximum length of the allocation) and if
> these aren't followed the extent size hints don't actually trim
> extents properly.
> 
> This patch set aims to unify alignment entirely via args->alignment
> and args->prod/args->mod. Alignment at both ends of the extent
> should always occur when the free space selected allows for start
> alignment of an extent that is at least args->minlen in length.
> 
> Hence we need to modify args->alignment setup to take into account
> extent size hints in addition to stripe alignment, and we need to
> ensure that extent length is always aligned to extent size hints,
> even if it means we cannot do a args->maxlen allocation.
> 
> This means that only when we completely fail to find aligned free
> space to allocate from will extent size hints no longer be start
> aligned. They will continue to be tail aligned up until we run out
> of contiguous free space extents large enough to hold an extent the
> size of a hint. Hence there is no real change of behaviour for
> extent size hints; they will simply prefer aligned allocations
> first, then naturally fall back to the current unaligned hint sized
> allocation strategy.
> 
> Unifying the allocation alignment stratgies simplifies the code,
> too. It means that the only time we don't align allocation is when
> trying to do contiguous allocation when extending the file (which
> should already be aligned if alignment is required!) or when there
> are no alignment constraints to begin with.  As a result, we can
> simplify the allocation failure fallback strategies and make the
> code easier to understand and follow.
> 
> Finally, we introduce a stub for force aligned allocation and add
> the logic fail the allocation if aligned allocation cannot be done.
> 
> This has run through fstests for some time here without inducing new
> failures or causing any obvious near-ENOSPC performance regressions.
>