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.