GNU bug report logs - #16539
df command, possible bug?

Previous Next

Full log

Message #25 received at 16539 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 16539 <at> debbugs.gnu.org, crubel <at> compro.net
Subject: Re: bug#16539: More details on df command output for you
Date: Sun, 26 Jan 2014 11:28:52 +0000

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.