[PATCH 0/2] xfs: fix a couple sparse chunk alloc problems
Brian Foster <[email protected]> Fri, 31 Jul 2026 12:33:35 -0400
| Newsgroups | org.kernel.vger.linux-xfs |
|---|---|
| Message-ID | <[email protected]> |
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/[email protected]/ 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