bug#37702: Suggestion for 'df' utility

[Bryce Harrington]

On Fri, Oct 11, 2019 at 12:56:20PM -0700, Paul Eggert wrote:
> On 10/11/19 11:20 AM, Pádraig Brady wrote:
> > 
> > if you want to exclude nested file systems like that,
> > you could try:
> > 
> >    alias df='df -x squashfs'
> 
> On my Fedora 30 workstation that option doesn't make any difference.
> Regardless of whether '-x squashfs' is used, I see this output from 'df':
> 
> Filesystem      1K-blocks      Used  Available Use% Mounted on
> devtmpfs          4065704         0    4065704   0% /dev
> tmpfs             4081560     36616    4044944   1% /dev/shm
> tmpfs             4081560      1696    4079864   1% /run
> tmpfs             4081560         0    4081560   0% /sys/fs/cgroup
> /dev/sda5        59614116  16910684   39645412  30% /
> tmpfs             4081560       124    4081436   1% /tmp
> /dev/sda2      1849433716 207781976 1547682948  12% /home
> /dev/sda1         5095040    244468    4572044   6% /boot
> tmpfs              816312        60     816252   1% /run/user/1000
> 
> and most of these lines are useless.
> 
> For many years we've put up with the problem of too many filesystems in the
> default plain 'df' output, and now's as good a time as any to fix that. On
> my workstation there should be only four lines of information, one each for
> /, /home, /boot, and the shared tmpfs area.
> 
> Presumably readonly filesystems should also be omitted by default, since
> they're not something people ordinarily care about.
> 
> We can add a flag or two for the rare people who want to see these
> normally-useless lines.

Hi,

I'd like to help in fixing this issue.  You're right that the popularity
of non-consumable filesystems (tmpfs, squashfs, etc.) has made df harder
to use for its primary use case of checking amount of available disk
space.  (On my current desktop (Ubuntu 20.04) df outputs 39 lines.)  It
seems reasonable to expect the number of these kinds of file systems is
only destined to increase.

It sounds like there are four approaches that could be taken:

  0.  Leave df as is
  1.  Heuristics
  2.  Config files
  3.  Env variable

I've taken a stab at a proof-of-concept implementation of #3, by adding
an environment variable DF_EXCLUDE_FSTYPES.  The current WIP draft of this
POC is available in this branch:

    
https://github.com/bryceharrington/coreutils/commit/2759c7abb085079abb80c9499ce88eda6f21b4e0

However, before I submit a patch officially, I'd appreciate your advice
on what the right approach to take *should* be.


Several heuristic ideas (approach #1) have been discussed in this bug
report:

  a) exclude all read-only file systems
  b) exclude read-only file systems with no free space
  c) exclude file systems with usage <=1%
  d) exclude devtmpfs and tmpfs explicitly by name
  e) ditto, and also read-only squashfs mounts

Concerns raised so far in this bug report with these heuristics include:
undesired side effects, compatibility troubles caused by changing
defaults, and preferences of package maintainers of different Linux
distributions.  It's unclear to me if there is a consensus yet.


>From a system integrator point of view, a config file approach makes a
lot of sense.  Different distros could set their own policies for what
fstypes to display via /etc/*/df.conf or something, and sysadmins would
be able to override per-system.  If support for a userspace config file
was provided (e.g. ~/.config/coreutils/df.conf, ~/.shellrc or similar)
then it would allow users to customize behavior as well.

However, from what I can tell nothing in coreutils uses config files, so
while config file code is certainly not exotic, this would be charting
new territory for coreutils as a project.  It also seems a bit invasive
to add config file support for just a single parameter.  Further, even
with a config file users would probably want a cli switch and/or env var
to override the config file settings.  I'm curious about your thoughts
and advice on these points particularly.


The env var approach sidesteps some of the above concerns but has issues
of its own.  First, depending on which startup file they're placed in,
they may not be visible to all services, or to different tool
environments such as sudo, su, systemd-nspawn, lxc exec, chroot,
schroot, etc.  Second, a top-level env var will consume a bit of memory
- small, but present even in processes that will never call df.


Given the above, I still think the env var approach strikes the right
balance for coreutils.  However, I would very much appreciate your
advice and direction, and look forward to finding a satisfactory
resolution for this problem.

Thanks,
Bryce