Adjusting what fstypes df displays

[Sergio Durigan Junior]

On Friday, May 29 2020, Bryce Harrington wrote:

> These days, df displays a lot of mount points, due to the increased use
> of non-consumable filesystems such as tmpfs and squashfs.  This clutter
> is particularly noticeable using df in Ubuntu, due to the increased
> popularity of snaps, but the general problem affects all Linux distros,
> and shows up in other commands such as lsblk, blkid, fdisk -l, and
> mount.
>
> A commonly documented user customization[1] is to use aliases, e.g.:
>
>     alias df='df -h -x squashfs -x tmpfs -x devtmpfs'
>     alias lsblk='lsblk -e 7'
>
> df's upstream is aware of the issue, and would like to address it in
> their code.  They've considered a number of solutions[2], but do not
> appear to have come to a consensus as of yet.  Among the raised concerns
> are variations in distro requirements, and providing an ability for
> users to override/customize the exclusions.
>
> A solution I am considering to propose would add an environment
> variable, DF_EXCLUDE_FSTYPES, that df would treat similar to the -x
> flag.
>
>
> I've drafted a POC implementation for df here:
>
>   https://github.com/bryceharrington/coreutils/commit/cc372d778b44abcf81af42743a5174685f9bb4db

Hey Bryce,

Overall I like the idea of using an environment variable to control this
behaviour, but I feel compelled to raise the point of discoverability.

If the distro ships a file under /etc/profile.d/ which silently sets
this variable for all users, and if the user is not aware of that, it
may take her some non-trivial effort to figure out why her tmpfs mount
is being listed by df.

I'm sure you must have thought of that, but if you go forward with the
environment variable idea, extra care will need to be taken when writing
the documentation for it.  Perhaps (and that's a big "perhaps"; I
haven't thought much about it) it's even worth mentioning somehow that
DF_EXCLUDE_FSTYPES is being used in the output of df, or having a new
"--full-output" option (or some such) that would ignore the variable and
print everything.

> Here's what it does inside a container...
>
> Before:
>
>     $ df
>     Filesystem                   1K-blocks      Used Available Use% Mounted on
>     default/containers/coreutils  24891008   2258816  22632192  10% /
>     none                               492         4       488   1% /dev
>     udev                          32862724         0  32862724   0% /dev/tty
>     tmpfs                              100         0       100   0% /dev/lxd
>     /dev/nvme0n1p2               982940092 348781368 584158392  38% /home/bryce/pkg
>     tmpfs                              100         0       100   0% /dev/.lxd-mounts
>     tmpfs                         32892912         0  32892912   0% /dev/shm
>     tmpfs                          6578584       224   6578360   1% /run
>     tmpfs                             5120         0      5120   0% /run/lock
>     tmpfs                         32892912         0  32892912   0% /sys/fs/cgroup
>     tmpfs                          6578580         0   6578580   0% /run/user/1001
>
> After:
>
>     $ export DF_EXCLUDE_FSTYPES=tmpfs,devtmpfs,squashfs
>
>     $ df
>     Filesystem                   1K-blocks      Used Available Use% Mounted on
>     default/containers/coreutils  24891008   2258816  22632192  10% /
>     /dev/nvme0n1p2               982940092 348781372 584158388  38% /home/bryce/pkg
>
> (It's even more drastic on my desktop - from 39 lines down to 6.)
>
> For Ubuntu, DF_EXCLUDE_FSTYPES could be set in the global profile (under
> /etc/profile.d/ perhaps?)  This would make it straightforward to add
> new non-consumable filesystems that may crop up down the road.  Perhaps
> other tools could use a similar/same env var approach, giving us a
> uniform way to control fs listings in the distro.
>
> Two alternate approaches I'm weighing are a config file in /etc, or just
> a package patch to carry in coreutils, but the env var approach feels
> like it would be more flexible to users and hopefully more suitable for
> upstream.  Before I forward it upstream, though, what does ubuntu-devel@
> think?

I kind of like the idea of a configuration file, but I agree that an
environment variable is more flexible.  Also, I don't think the creation
of a configuration file would be justified for just this single option.

Let me know when you submit the patch upstream; I'm interested in
following the discussions :-).

Thanks,

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14