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@xxxxxxxxxxxxx/ 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@xxxxxxxxxxxxx/) 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@xxxxxxxxxxxxx
