Re: [RFC PATCH 7/7] btrfs: zoned: add RECLAIM_ZONES and RESET_ZONES to first async reclaim loop

[Boris Burkov <boris@bur.io>]

On Wed, May 13, 2026 at 02:34:45PM +0200, Johannes Thumshirn wrote:
> On zoned filesystems, when waiting for space tickets during data
> relocation, the async reclaim flush state machine may starve if
> RECLAIM_ZONES and RESET_ZONES states are not executed early in the flush
> sequence.
> 
> Currently do_async_reclaim_data_space() only executes RECLAIM_ZONES and
> RESET_ZONES in later flush states (FLUSH_DELALLOC and beyond), but by
> the time these states are reached, the ticket wait may have already
> deadlocked waiting for space that can only be freed by zone reset.

This explanation is a bit confusing to me. Does your previous fix
prevent all known deadlocks? If not, can you describe the remaining
deadlock in more detail? If having these flush states in the general
flush state list causes a deadlock, we should not leave them there, even
if we add this earlier pass.

I assume the issue is that some other flusher can't make progress when
we are out of zones and also lands on a ticket, and so async reclaim is
stuck on a ticket and the only way to make progress is to reset a zone
(hopefully) or reclaim a zone (painfully?)

Maybe we need some high level flushing logic like "needs zoned help now
please"? i.e., if we are low/out of free zones, do only zone flushing,
otherwise do regular flushing (including zoned stuff if necessary/wise?)

> 
> Fix this by adding RECLAIM_ZONES and RESET_ZONES to the first async
> reclaim loop (FLUSH_ALLOC) for zoned filesystems, ensuring zone reset
> happens early enough to free space for pending allocation tickets.
> 
> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
> ---
> 
> This patch was AI assisted and I'm not sure this is the correct thing to
> do (the flushing, not the use of AI), hence the RFC tag. 
> 
>  fs/btrfs/space-info.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c
> index ec811a77ebb1..a1235f114f3e 100644
> --- a/fs/btrfs/space-info.c
> +++ b/fs/btrfs/space-info.c
> @@ -1451,6 +1451,17 @@ static void do_async_reclaim_data_space(struct btrfs_space_info *space_info)
>  
>  	while (!space_info->full) {
>  		flush_space(space_info, U64_MAX, ALLOC_CHUNK_FORCE, false);
> +		/*
> +		 * For zoned filesystems, also run RECLAIM_ZONES and RESET_ZONES
> +		 * in the first loop to avoid starvation. Zoned filesystems have
> +		 * sequential write requirements, so space cannot be reused until
> +		 * zones are reset. Running these states early ensures zones are
> +		 * reclaimed and reset before we get into a starvation situation.
> +		 */
> +		if (btrfs_is_zoned(fs_info)) {
> +			flush_space(space_info, U64_MAX, RECLAIM_ZONES, false);
> +			flush_space(space_info, U64_MAX, RESET_ZONES, false);
> +		}

Just to set a common ground on the existing algorithm:
The current logic is to allocate a chunk (which may satisfy tickets)
then check if we have any tickets left. If not tickets left, great we're
done. Else, allocate another chunk (till full). Finally, go into the
various flushers if we can't allocate a chunk.

The way you have changed it, you tack on the two zoned specific flushes
right after allocating a chunk, regardless of the continued presense of
tickets. That feels off to me. I don't know enough about zoned to
accurately judge how you want to order it, but I think the question you
want to answer for yourself is:

If there are totally free bgs on a zoned fs, do I want to run
reclaim/reset zones before or after allocating them?

Given the fixed number of zones, I would assume reset zones at least
should come before grabbing a fresh bg? (Unless that fails in a free
zone aware way?)

OTOH, if you put zoned reclaim before chunk alloc, we may block data
allocations on pretty expensive reclaim work when we could just make
progress now by allocating a chunk.

Long term, I am planning to refactor space flushing to try to make the
separate work less sequential and driven by the demand for the
particular type of flushing, but that is way longer term than your
immediate need. I am just saying that to hopefully make the pain of the
"ordering" aspect a bit more clear in greater context, it's not zoned
specific. (it's bad to keep running delalloc first if we have a bunch
of ordered extents out and should instead run delayed refs or commmit a
txn to unpin, e.g.)

>  		spin_lock(&space_info->lock);
>  		if (list_empty(&space_info->tickets)) {
>  			space_info->flush = false;
> -- 
> 2.54.0
>