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
