Re: [XFS] Question: can xfs_agfl_free_finish_item exhaust AGFL during bnobt/cntbt split?

[Dave Chinner <dgc@kernel.org>]

On Mon, Apr 13, 2026 at 10:48:51AM +0800, Jinliang Zheng wrote:
> On Mon, 13 Apr 2026 10:14:45 +1000, dgc@kernel.org wrote:
> > On Mon, Apr 13, 2026 at 12:32:50AM +0800, Jinliang Zheng wrote:
> > > But before `xfs_agfl_free_finish_item` executes, `xfs_defer_finish_noroll`
> > > rolls the transaction. Other deferred operations that execute in between—for
> > > example, regular extent frees (`XFS_DEFER_OPS_TYPE_FREE`) that themselves call
> > > fix_freelist and may re-shrink the AGFL, or rmapbt operations—could consume
> > > AGFL blocks and leave the count below `need` by the time our deferred AGFL free
> > > runs.
> > 
> > Even if we run RUIs, CUIs or other EFIs before the AGFL deferred
> > free, they fix up the freelist for their operations first, and that
> > reserves space for a deferred AGFL free from the free list.
> > 
> > If any other extent allocation/free on that AG is run between the
> > two transactions (e.g. high level transactions racing on AGF buffer
> > access) they will also reserve space in the AGFL for a split during
> > a deferred free.
> 
> Thank you for the detailed explanation. I have a follow-up question about
> the case where fix_freelist shrinks the AGFL by more than one block.
> 
> When `xfs_alloc_fix_freelist` shrinks an oversized AGFL, it may call
> `xfs_defer_agfl_block` multiple times in a loop, adding N deferred AGFL
> free items into the same `xfs_defer_pending` (up to max_items=16 per
> pending entry).
> 
> In `xfs_defer_finish_noroll`, all N items within that single
> `xfs_defer_pending` are processed consecutively in the same rolled
> transaction via `list_for_each_safe`, with no intervening fix_freelist
> call between them. Each call to `xfs_agfl_free_finish_item` invokes
> `xfs_free_ag_extent`, which may trigger a full-height split of both bnobt
> and cntbt, consuming up to `(bnobt_levels + 1) + (cntbt_levels + 1)`
> AGFL blocks.
>
> The initial fix_freelist leaves the AGFL at exactly `need` blocks. If
> the first deferred free triggers a full-height bnobt+cntbt split and
> consumes those blocks, the AGFL may already be below `need` — or even
> exhausted — by the time the second deferred free runs and needs to split.
> 
> Is this scenario considered?

I have considered it, yes.

Remember what I said about considering the probability of something
occurring before adding complexity to guarantee it will never
happen.

The above scenario requires both allocbts and the AGFL to be set up
in such a way that it has multiple full subtrees ready to split in
both trees, and that the same block frees (from the AGFL) will
trigger those subtree splits with the same free space record insert.

And the AGFL has to have exactly the right blocks on it *in excess
of what is required* in to get them deferred in the right order to
then trigger these subtree splits.

And this has to happen multiple times in consecutive operations.

Can the above happen? Yes.

Will it happen by chance before the heat death of the universe? Probably.

Will it happen in production workloads?  Not very likely at all.

That's the difference between providing theoretical guarantees vs
practical guarantees.

We can keep playing "but what if we had N+1" type theoretical
scenarios endlessly here, but reality has to step in at some point.
We set reservation sizes for "unbound excursions" at a size that is
large enough for normal operation and largely ignore the cases with
10^(large negative N) probabilites.

If, in practice, we find the reservation pools are getting exhausted
in normal production workloads, then we'll either change the
behaviour that is causing the exhaustion or increase the reservation
pool size to handle that case.

-Dave.

-- 
Dave Chinner
dgc@kernel.org