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

[Pádraig Brady]

On 01/25/2014 11:55 PM, Bernhard Voelker wrote:
> On 01/25/2014 04:19 AM, Pádraig Brady wrote:
>> On 01/24/2014 10:27 PM, Bernhard Voelker wrote:
>>> The above is the result of df suppressing duplicate entries like
>>> bind mounts.  This filtering is done based on the device number.
>>> As this example shows, a few exports of directories of the same file
>>> system from "host" are mounted - yet it's the same file system.
>>
>> Right. Essentially df is showing storage for available file systems.
>> Noting that df also has a --total option, it makes sense by default
>> to not repeat file systems. This can be overridden easily with the
>> -a option as noted above.
>>
>> Actually we should in fact be merging more entries!
>> Notice the following:
>>
>>>> tmpfs                 4095336     4688   4090648   1% /run
>>>> tmpfs                 4095336     4688   4090648   1% /var/run
>>>> tmpfs                 4095336     4688   4090648   1% /var/lock
>>
>> Hopefully the attached patch addresses this
>> (and a couple of other test issues).
> 
> Good idea.
> 
> I think we're on the right way - and the patch looks good to me.

Thanks for the review. I'll handle the syntax check too.

> However, I remember some other corner cases with eclipsed file
> systems in the Fedora bug tracker. I think we're quite close
> to solve them all this time (hopefully).
> The idea was to trust the order of mount entries returned by
> the kernel, i.e. in the loop over the mount entries, if the
> mount point is the same one as a previous one, then we should
> process the one mounted later.
> 
> E.g. the situation where 2 file systems are mounted on the
> same mount point:
> 
>   $ findmnt | grep loop
>   └─/mnt                           /dev/loop0     ext4                
> rw,relatime,data=ordered
>     └─/mnt/dir                     /dev/loop1     ext4                
> rw,relatime,data=ordered
>       └─/mnt/dir                   /dev/loop2     ext4                
> rw,relatime,data=ordered
> 
> df - the new one with your patch - still shows the wrong device:
> 
>   $ src/df | grep loop
>   /dev/loop0        122835      1551    112110   2% /mnt
>   /dev/loop1        122835      1550    112111   2% /mnt/dir
> 
> It should say /dev/loop2 here. BTW the numbers are correct.

Right, that could be handled easy enough.
loop1 is not accessible above and so should be hidden.
But consider a bind mount resulting in something like:

>   └─/mnt                           /dev/loop0     ext4                
> rw,relatime,data=ordered
>     └─/mnt/dir                     /dev/loop1     ext4                
> rw,relatime,data=ordered
>       └─/some/place/else           /dev/loop1     ext4                
> rw,relatime,data=ordered
>       └─/mnt/dir                   /dev/loop2     ext4                
> rw,relatime,data=ordered

If we did a linear scan through that, we'd lose the /some/place/else
due to it being a longer mount dir, and then also the original loop1
as we took /dev/loop2 for /mnt/dir.
Seems like when discarding we would need to see if this was the
last entry for a device and then see if there are any other candidate
mount points for that device?

thanks,
Pádraig.