Re: [PATCH 5/7] btrfs: zoned: subtract zone_unusable space in statfs

[Boris Burkov <boris@bur.io>]

On Fri, May 15, 2026 at 01:34:30PM +0200, Christoph Hellwig wrote:
> On Fri, May 15, 2026 at 11:26:22AM +0200, Johannes Thumshirn wrote:
> > On 5/15/26 6:39 AM, Christoph Hellwig wrote:
> >> On Wed, May 13, 2026 at 02:34:43PM +0200, Johannes Thumshirn wrote:
> >>> On zoned filesystems, space in block groups that has been freed but not
> >>> yet reset is tracked in bytes_zone_unusable. This space cannot be used for
> >>> new allocations until zone reclaim resets the zones, but it was being
> >>> reported as available space in statfs.
> >>>
> >>> This caused statfs to over-report free space, leading to ENOSPC errors
> >>> when applications tried to allocate based on the reported free space.
> >>>
> >>> Fix this by subtracting bytes_zone_unusable from total_free_data in the
> >>> statfs calculation for zoned filesystems.
> >> This OTOH sounds very wrong.  Freed but not reclaimed space is usable,
> >> it just needs work.
> >>
> > man statfs says:
> >
> >                fsblkcnt_t f_bavail;  /* Free blocks available to
> >                                         unprivileged user */
> >
> > which in my interpretation would include zone_unusable_bytes, as they're 
> > not "free blocks available". Or would that be accounted as f_bfree?
> 
> The only different between f_bavail and f_bfree is reservations for
> the superuser, which IIRC only extN do on Linux.
> 
> f_bavail is all the space you as a user could potentially use on
> the file system (modulo quota restrictions).

I think it would be great to discuss this in more detail. The whole
"reservations for the superuser" thing never made a huge amount of sense
to me, and feels sort of under-specified.

I take it to spiritually mean "space allocated to other crap definitely
needed to do your data allocation anyway". So in btrfs that would
mean something like "an estimate of how much metadata you would need for
the remaining space"?

Returning to the actual implementation and this concrete question:

AIUI, we calculate f_bavail as unaware of any stranded metadata space
we could free up by running a 'btrfs balance start -m', for example.
Furthermore, there is a discontinuity to zero in edge cases when
potential space for metadata is exhausted even if there is still space
allocated for data.

So I think Johannes's change certainly fits with that (and the raid
aware) nature of the bavail calculation.

On the other hand, given that the zone reclaiming is guaranteed to
happen automatically, I can see how it could be treated differently,
though, unlike the metadata balancing. But if we made metadata
balancing happen automatically in a flusher, we would need to change
f_bavail to count stranded metadata space too?

There was another recent discussion on this, where you said we should
avoid over-estimating:
https://lore.kernel.org/linux-btrfs/efcb3c8470bf099534fec1c1745780eba445e111.1774394322.git.loemra.dev@gmail.com/

So I think the main thing is whether btrfs guarantees it will succeed on
allocations given space stranded in zones is available "after a balance"
or not? Should it admit those writes? (Is this the right test?)

I think in this case, given that balance is in a flusher, it should, but
it is better to say "everything" out loud to leave less to the
imagination. And we should confirm that this property really holds, that
such a write will succeed after painful extra balancing work. It is
possible the balance fails, for example, due to insufficient free space
for a large extent that needs balancing. Maybe because of the reloc zone,
that isn't true for zoned? Either way, does that aspect of it change how
we feel?

Thanks,
Boris