From: Matt Fleming <matt@readmodwrite.com>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org, Carlos Maiolino <cem@kernel.org>,
"Darrick J . Wong" <djwong@kernel.org>,
Dave Chinner <dchinner@redhat.com>,
Christoph Hellwig <hch@lst.de>,
linux-kernel@vger.kernel.org, kernel-team@cloudflare.com
Subject: Re: [BUG] xfs: sparse inode allocation can trip i != 1 after AGFL growth
Date: Mon, 20 Jul 2026 11:37:25 +0100 [thread overview]
Message-ID: <al33dUXS_8Yr5vEu@matt-Precision-5490> (raw)
In-Reply-To: <alpsniDzp5kWl0xA@bfoster>
On Fri, Jul 17, 2026 at 01:55:42PM -0400, Brian Foster wrote:
> On Fri, Jul 17, 2026 at 02:04:29PM +0100, Matt Fleming wrote:
> >
> > The failure sequence seems to be:
> >
> > 1. AG0 has no free inodes, so inode allocation needs a new chunk.
> > 2. Full chunk allocation cannot fit.
> > 3. Sparse chunk allocation can fit and passes the old AGFL minimum check.
> > 4. Removing the sparse extent from free space grows both bnobt and cntbt.
>
> I assume this means we happen to alloc a sparse chunk out of the middle
> of a free extent, causing an additional record and thus splits in both
> trees.
Yep, exactly.
> It also looks like we set args.minleft = igeo->inobt_maxlevels in the
> chunk alloc path, presumably with the intent to leave enough blocks
> around for inode record insertion. I assume the above available value is
> prior to the sparse chunk alloc. It would be interesting to see what the
> same values/calculations are after the chunk alloc at the time of the
> inobt block alloc that fails.
Before sparse inode allocation:
pagf_freeblks: 2514
pagf_flcount: 8
levels: bno/cnt/rmap = 1/1/2
reservation: 2505
minleft: 2
min_freelist: 8
AGFL credit: min(8, 8) = 8
available:
2514 + 8 - 2505 - 8 - 2 = 7
request:
minlen=4 align=4 slop=0
alloc_len = 4 + (4 - 1) + 0 = 7
So the sparse inode allocation only just passes the allocator check.
After sparse inode allocation, at the failing inobt split allocation:
pagf_freeblks: 2510
pagf_flcount: 4
levels: bno/cnt/rmap = 2/2/2
reservation: 2505
minleft: 0
min_freelist: 12
AGFL credit: min(4, 12) = 4
available:
2510 + 4 - 2505 - 12 - 0 = -3
request:
minlen=1
So after removing the 4-block sparse extent, bnobt/cntbt have grown,
AGFL has dropped, min_freelist has increased from 8 to 12, and the
later single-block inobt allocation has no available space.
Thanks,
Matt
prev parent reply other threads:[~2026-07-20 10:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 13:04 [BUG] xfs: sparse inode allocation can trip i != 1 after AGFL growth Matt Fleming
2026-07-17 17:55 ` Brian Foster
2026-07-20 10:37 ` Matt Fleming [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=al33dUXS_8Yr5vEu@matt-Precision-5490 \
--to=matt@readmodwrite.com \
--cc=bfoster@redhat.com \
--cc=cem@kernel.org \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=kernel-team@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.