Re: [PATCH] btrfs: statfs: Don't reset f_bavail if we're over committing metadata space

[David Sterba <dsterba@suse.cz>]

On Fri, Jan 17, 2020 at 10:16:45PM +0800, Qu Wenruo wrote:
> >> But this behavior itself is not accurate.
> >>
> >> We have global reservation, which is normally always larger than the
> >> immediate number 4M.
> > 
> > The global block reserve is subtracted from the metadata accounted from
> > the block groups. And after that, if there's only little space left, the
> > check triggers. Because at this point any new metadata reservation
> > cannot be satisfied from the remaining space, yet there's >0 reported.
> 
> OK, then we need to do over-commit calculation here, and do the 4M
> calculation.
> 
> The quick solution I can think of would go back to Josef's solution by
> exporting can_overcommit() to do the calculation.
> 
> 
> But my biggest problem is, do we really need to do all these hassle?

As far as I know we did not ask for it, it's caused by limitations of
the public interfaces (statfs).

> My argument is, other fs like ext4/xfs still has their inode number
> limits, and they don't report 0 avail when  that get exhausted.
> (Although statfs() has such report mechanism for them though).

Maybe that's also the perception of what "space" is for users. The data
and metadata distinction is an implementation detail. So if 'df' tells
me there's space I should be able to create new files, right? Or write
more data, but still looking at the same number of free space.

For ext2 or ext3 it should be easier to see if it's possible to create
new inodes, the values of 'df -i' are likely accurate because of the
mkfs-time preallocation.

Newer features on ext4 and xfs allow dynamic creation of inodes, you can
find guesswork regarding the f_files estimates.

I vaguely remember that it's possible to get ENOSPC on ext4 by
exhausting metadata yet statfs will still tell you there's free space.
This is confusing too.