Mailinglist Archive: opensuse-factory (602 mails)

< Previous Next >
Re: [opensuse-factory] zypper dup disk space requirement
  • From: Joachim Wagner <jwagner@xxxxxxxxxxxxxxxx>
  • Date: Fri, 08 Feb 2019 08:51:10 +0000
  • Message-id: <2249079.5Xv4eavHmq@linux-ojn4>
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups