Re: [PATCH] xfs: don't include bnobt blocks when reserving free block pool

[Dave Chinner <david@fromorbit.com>]

On Wed, Mar 16, 2022 at 02:15:26PM -0700, Darrick J. Wong wrote:
> Yeah, I at least like the idea of having a function that estimates how
> much free space we can try to reserve without using reserve pool blocks.
> I also am warming to the idea of telling users they can't have /any/ of
> those reserved blocks... particularly since I haven't even gotten to the
> "I fill my fs to 99% full and only then buy one more gigabyte of space,
> wash, rinse, repeat" complaints.

Go look at what I considered for the "thinp aware" filesystems a few
years ago:

https://lore.kernel.org/linux-xfs/20171026083322.20428-1-david@fromorbit.com/

The available space the filesystem presented to the user is
completely divorced from the physical device block count and
internal filesystem metadata space usage. Users simply didn't see
any of the space we reserved for metadata as space they could
allocate. i.e. it split the superblock sb_dblocks value away from
the number of data blocks we present to the user that they can
allocate as user data.

(https://lore.kernel.org/linux-xfs/20171026083322.20428-10-david@fromorbit.com/)

So, yeah, moving towards a model that essentially hides all the
reserved space from users and only presenting them with the amount
of space that is available without dipping into any reserves would
make things an awful lot simpler from an architectural POV...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com