bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#37702: Suggestion for 'df' utility


From: Assaf Gordon
Subject: bug#37702: Suggestion for 'df' utility
Date: Sun, 13 Oct 2019 16:13:55 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

Hello Bernhard,

On 2019-10-13 3:57 p.m., Bernhard Voelker wrote:
On 2019-10-13 23:28, Paul Eggert wrote:
In any sane system there would be only
four lines of non-header output (for tmpfs etc, /, /home, and
/media/eggert/B827-D456), but df is outputting 28 lines.

What is so special about tmpfs so that you would like to see it?

As an interesting use-case (though not common),
I recently configured a raspberry PI device,
and wanted to mount as many locations on tmpfs as possible,
e.g. "/tmp" "/var/tmp", "/var/log" etc.

In was very useful in those cases to be able to see separate
tmpfs file system listed, with information about how big they
are and how much space was used.

Also in other systems where "/tmp" is a "tmpfs",
users might want to see how much space is available.

If we hide it by default, they can of course use "df /tmp"
or "df --all" - it's not about removing this option,
it is just about making users' life harder or easier,
and making unexpected changes.


I recently also encountered a change in a default behavior of
a program which I've been using a very long time - and it is *very*
frustrating to have something that worked "just fine" for so long
being changed.


Here on my openSUSE:Tumbleweed system, I see the following:

   $ df -T
   Filesystem     Type     1K-blocks      Used Available Use% Mounted on
[...]
   /dev/loop0     ext2         31729     31729         0 100% 
/FULL_PARTITION_TMPDIR
[...]

(The /FULL_PARTITION_TMPDIR is used by a special coreutils test.)


That's an interesting case, where I would think you'd want to see it,
because you explicitly mounted it.


I think I could well live with adding 'devtmpfs' and 'tmpfs' to the
pseudo file systems in gnulib's "mountlist.c".

I agree, but think this needs to be communicated very well,
and in advance - perhaps announce this change ahead of time to
the respective package maintainers of each distribution - just so
they'll know it's coming (and also have a way to revert it if they don't
like it).


This seems to be a small change, and not satisfying the snap case.

Possibly hiding "squashfs" of readonly-mounts could get rid of those snaps?

regards,
  -assaf






reply via email to

[Prev in Thread] Current Thread [Next in Thread]