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.
