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

[Christoph Hellwig <hch@lst.de>]

On Fri, May 15, 2026 at 02:05:11PM -0700, Boris Burkov wrote:
> > 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.

It is, and the fact that most file systems never implemented it probably
means it isn't very relevant.  Buf if you're interested in you should
probably ping Ted or Al.

> 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"?

I don't really unnderstand what you mean here, and how it would relate
to reservations for the root user.  Remember that these definitions are
from a time where there was very little dynamic metadata, and the size
of it was trivial to estimate.  Basically just directory entries with
a tiny overhead over the file name, and indirect blocks for file data.

> 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?

the bfree/bavail needs to fit too criteria:

 1) vaguely estimate the amount of space that can still be used
    on the file system
 2) don't over-promise

And this patch fails on 1).  Once you've filled a zoned file system
entirely with a normal non-optimize write pattern, and then delete
a lot of this again, either at once or in small increments, with this
change statfs would permanently report a value close to 0, which is
very wrong.

IFF btrfs automatically reclaimed metadata (and I think it should),
it should be treasted the same zoned data and be reported as
free/available in statfs.