bug#16539: More details on df command output for you

[Bernhard Voelker]

On 01/27/2014 02:06 AM, Pádraig Brady wrote:
> On 01/26/2014 11:35 PM, Bernhard Voelker wrote:
>> Now, how should df handle this?
>>
>> a)
>> df silently filters out the mount entries of all eclipsed mount dirs,
>> even with -a.
>> --> Hmm, I think this would probably contradict to POSIX.
>>
>> b)
>> df prints an error diagnostic for each eclipsed mount dir, and exits
>> non-Zero.
>> --> Well, there are probably such mounts on every system, e.g. on my box:
>>
>>   TARGET                       SOURCE         FSTYPE
>>   /proc/sys/fs/binfmt_misc     systemd-1      autofs
>>   /proc/sys/fs/binfmt_misc     binfmt_misc    binfmt_misc
>>
>> Therefore, a "df -a" would always fail. ;-(
>> At least on my system, there are
>>
>> c)
>> df prints a warning diagnostic for each eclipsed mount dir, and exits
>> Zero (unless another error occurs).
>>
>> --> Due to the same reason as in b), these warning might be messy
>> and users will probably be irritated.
>>
>> d)
>> df outputs "-" for all numbers of such eclipsed file systems, e.g.
>>
>>   $ src/df --out -h -a | grep mnt1
>>   /dev/loop0     ext4                     -     -     -     -     -     -    
>>  -    - -    /mnt1
>>   /dev/loop1     xfs                   256K     3  256K    1%  252M   13M  
>> 239M   6% -    /mnt1
>>
>>
>> Maybe d) is the best solution, as it mirrors what df can know:
>> it knows source, target and the file system type, but it doesn't
>> have access to the block and inode numbers.
>>
>> WDYT?
> 
> Thanks for the nice analysis and tests.
> d) seems like the best option here, though we'd have to be careful
> about cases where /proc/mounts was giving a system wide view,
> while df wasn't privy to that due to mount namespaces or
> overmounts etc. I'm not thinking of a specific issue here,
> just the general problem.

okay, let's try it that way.
I think this is not much related to the issue your patch (with my
amendment) is trying to fix.  Therefore, I suggest to finish that
and handle the overmounts in a separate commit.

> wrt c) and annoying warnings, I also notice `df -a` on a default Fedora 20 
> install here,
> giving multiple duplicate warnings like:
>   df: ‘net:[4026532416]’: No such file or directory
>   df: ‘net:[4026532416]’: No such file or directory
> That's due to:
>   $ grep net: /proc/mounts
>   proc net:[4026532416] proc rw,nosuid,nodev,noexec,relatime 0 0
>   proc net:[4026532416] proc rw,nosuid,nodev,noexec,relatime 0 0
> Which is due to support for namespaces.

Ugh ... and that's a third problm class for df. ;-(

> Seems like we should not try to lookup non absolute mount points?

yes, that's probably our best chance.

> Also a general point is that a lot of stuff has changed underneath us 
> recently,
> and perhaps we should be looking at abstracting that away somewhere
> (like libmount that is part of util-linux). In the short term anyway
> we should fix up the above warts within df.

I'm not sure about such an abstraction.  Actually, the mount_list is already
abstracted ... by gnulib. And that's the biggest difference to the situation
in util-linux: while util-linux only has to run on GNU/Linux, coreutils' df
has to run on a big variety of systems including far-off systems like cygwin.
I think if we find a way to ignore such non-accessible file systems without
producing too many annoying warnings, then I'd say we're off the hook.
Namespaces have been invented to hide mounts, so people shouldn't wonder
that they are hidden to df. ;-)

Have a nice day,
Berny