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.
