Re: [PATCH v2 07/13] xfs: Introduce FORCEALIGN inode flag

John Garry
2024-07-24T18:50:36Z

On 24/07/2024 01:04, Darrick J. Wong wrote:
>> So why not just enable the per-inode flag with RT right from the
>> start given that this functionality is supposed to work and be
>> globally supported by the rtdev right now? It seems like a whole lot
>> less work to just enable it for RT now than it is to disable it...
> What needs to be done to the rt allocator, anyway?
>
> I think it's mostly turning off the fallback to unaligned allocation,
> just like what was done for the data device allocator, right? And
> possibly tweaking whatever this does:
>
> /*
> * Only bother calculating a real prod factor if offset & length are
> * perfectly aligned, otherwise it will just get us in trouble.
> */
> div_u64_rem(ap->offset, align, &mod);
> if (mod || ap->length % align) {
> prod = 1;
> } else {
> prod = xfs_extlen_to_rtxlen(mp, align);
> if (prod > 1)
> xfs_rtalloc_align_minmax(&raminlen, &ralen, &prod);
> }
>
>

My initial impression is that calling xfs_bmap_rtalloc() ->
xfs_rtpick_extent() for XFS_ALLOC_INITIAL_USER_DATA won't always give an
aligned extent. However the rest of the allocator paths are giving
extents aligned as requested - that is from limited testing.

And we would need to not take the xfs_bmap_rtalloc() retry fallback for
-ENOSPC when align > rtextsize, but I have not hit that yet - maybe
because xfs_trans_reserve() stops us getting to this point due to lack
of free rtextents.