[PATCH 0/2] xfs: fix a couple sparse chunk alloc problems

[Brian Foster <bfoster@redhat.com>]

Hi all,

This series is a couple small sparse chunk alloc related fixes. Patch 1
is LLM detected and generated (I rewrote the commit log) during the
process of investigating the problem fixed by the second. Patch 2 fixes
the problem reported by Matt here [1].

Note that patch 2 is semi-RFC. Personally I'm Ok with using this as the
fix, but I don't love it and recognize that it's more of a band-aid. The
fundamental problem seems more that the space availability requirements
change within a transaction that targets a single AG, but I haven't yet
thought of an elegant enough way to fix that for something that is kind
of a corner case.

The LLM came up with a fix that basically bumps up minleft within the
allocator path by the extra space that would be required by the inobt
allocation, but I didn't really like that at all and tossed it in favor
of this.

I had a couple other things I thought about as potential alternatives.
One is to perhaps use or repurpose something like the
XFS_ALLOC_FLAG_FREEING flag for this pattern where we have a minleft
gated allocation followed by a targeted alloc to the same AG. This would
presumably allow the allocation to succeed.

Another is to perhaps enhance the xfs_alloc_min_freelist() logic to just
start to use the allocbt maxlevels value for requirements calculation as
an AG starts to approach -ENOSPC. That is more of a heuristic and
similar sort of workaround for the problem, but more directly encodes
that reliability is priority over squeezing every last block from an AG.
I also think it's a little risky as it may involve a new mode of
allocation across the board (not just sparse chunk allocs).

I also suspect this wouldn't be a problem if the inobt were covered as
perag metadata res the way the finobt is, but I haven't thought that
through fully.

So all in all I'm curious what folks think about any of this or have any
other potential ideas. My main concern is that I don't want to introduce
something too complex for the single uncommon use case of sparse inodes.
I.e., this problem seems a lot like a corner case of a corner case to
me. Thoughts?

Brian

[1] https://lore.kernel.org/linux-xfs/20260717130429.1838767-1-matt@readmodwrite.com/

Brian Foster (2):
  xfs: set minleft correctly for sparse chunk errortag allocation
  xfs: consistent low ag space behavior for sparse inode chunk allocs

 fs/xfs/libxfs/xfs_ialloc.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

-- 
2.55.0