Au contraire: I'm the only one pointing out that df(1) is not the culprit, and instead it is just outputting the information is gets. If that information is misleading for the user, then either the source of that numbers has to be changed, or - if that is impossible because the df fields 'itotal', 'iused', 'iavail', 'ipcent', 'size', 'used', 'avail', 'pcent' do not make 100% sense in the context of BTRFS - I prefer to amend the documentation to describe those possible pitfalls for the user at least.
I am not a BTRFS user nor a kernel hacker; my point of view is that of a GNU coreutils contributor (upstream+downstream). Therefore, I try to fight the over-simplifying "df spits out useless nonsense for BTRFS", and see that the best solution for the GNU coreutils users is to document the specialties for this file-system somewhere.
Putting "(estimated)" directly next to the value is likely to break user's scripts that extract information from df output. Maybe a footnote in the df output would be acceptable. However, I don't think it's a good idea to maintain code in df that tells it what filesystem can provide what information accurately (or where that field makes sense). The struct the kernel returns should have an indicator bit mask which fields are estimates / best effort replacement values. Furthermore, df and kernel documentation should tell whether itotal should be iavail + iused and size = used + avail or each value can be an independent best effort. Joachim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org