08.02.2019 3:43, Bernhard Voelker пишет:
On 2/7/19 6:51 PM, Andrei Borzenkov wrote:
07.02.2019 17:39, Bernhard Voelker пишет:
I disagree: as already stated, BTRFS does not expose the right (or useful?) numbers to the statfs(2) system call
Show kernel code where it does it and explain why the value it calculates is not right. This also presumes you know how to calculate it right - did you submit your patch to fix it?
It has been mentioned repeatedly that a user should run 'btrfs filesystem usage /' to get the "correct" numbers (whatever they are), and: "df spit out useless nonsense".
So you do not actually know anything about it, you just repeat what others say.
I wouldn't go that far: I don't think the numbers df(1) gets from statfs(2) are totally wrong, but it is obviously not transparent for the user how to interpret them in the context of a BTRFS file system, and incidentally such confusions mostly happen in critical situations near ENOSPC.
I don't want to (and don't have time to) fix anything in the kernel - especially wrt/ btrfs - , but I'd be willing to discuss with the other coreutils maintainers to add some snippet to the df documentation or on the FAQ page how a user could interpret BTRFS numbers.
This discussion is about estimating free space on root filesystem. None of other "BTRFS numbers" will give you anything that plain "df" does not already. Those "BTRFS numbers" may help to answer the question "where did my space go" but that is not the point of this thread.
What do these numbers actually tell for BTRFS / and what not? Or should it just link to https://btrfs.wiki.kernel.org/index.php/FAQ#Why_is_free_space_so_complicated... ?
Show me how to create filesystem with different per-subvolume profiles using SUSE installer (or manually for that matter). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org