On Wed, Mar 06, 2024 at 11:46:38AM +0000, John Garry wrote: > On 06/03/2024 05:20, Dave Chinner wrote: > > Hi Garry, > > > > I figured that it was simpler just to write the forced extent > > alignment allocator patches that to make you struggle through them > > and require lots of round trips to understand all the weird corner > > cases. > > I appreciate that. > > > > > The following 3 patches: > > > > - rework the setup and extent allocation logic a bit to make force > > aligned allocation much easier to implement and understand > > - move all the alignment adjustments into the setup logic > > - rework the alignment slop calculations and greatly simplify the > > the exact EOF block allocation case > > - add a XFS_ALLOC_FORCEALIGN flag so that the inode config only > > needs to be checked once at setup. This also allows other > > allocation types (e.g. inode clusters) use forced alignment > > allocation semantics in future. > > - clearly document when we are turning off allocation alignment and > > abort FORCEALIGN allocation at that point rather than doing > > unaligned allocation. > > > > I've run this through fstests once so it doesn't let the smoke out, > > but I haven't actually tested it against a stripe aligned filesystem > > config yet, nor tested the forcealign functionality so it may not be > > exactly right yet. > > > > Is this sufficiently complete for you to take from here into the > > forcealign series? > > > > I'll try it out. > > What baseline are these against? Mine were against v6.8-rc5, but I guess > that you develop against an XFS integration tree. Maybe they apply and build > cleanly against v6.8-rc5 ... 6.8-rc7 + linux-xfs/for-next + some other local patches to other parts of XFS that shouldn't overlap with this patch set. I don't think there's anything in for-next overlapping this code, so it might just apply cleanly to your tree.... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
