LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   COREUTILS 8.21 - 'df' bind mount bug. (http://www.linuxquestions.org/questions/slackware-14/coreutils-8-21-df-bind-mount-bug-4175453522/)

GazL 03-10-2013 12:45 PM

COREUTILS 8.21 - 'df' bind mount bug.
 
Just thought I'd make people aware of this one in case you hit it and wonder what the hell is going on (like I did)

Quote:

df now properly outputs file system information with bind mounts present on
the system by skipping duplicate entries (identified by the device number).
Consequently, df also elides the early-boot pseudo file system type "rootfs".
Now, I can understand the idea of hiding the duplicates, but it seems that they haven't quite figured out how to suppress the bind mount rather than the original filesystem.
Code:

root@ws1:~# df
Filesystem                  1K-blocks    Used Available Use% Mounted on
/dev/mapper/rootvg-lvroot    16382888  5847268  9696760  38% /
/dev/mapper/rootvg-lvlocal    83585712 75545448  8040264  91% /local
root@ws1:~# mount -o bind /local/music /mnt
root@ws1:~# df
Filesystem                  1K-blocks    Used Available Use% Mounted on
/dev/mapper/rootvg-lvroot    16382888  5847268  9696760  38% /
/local/music                  83585712 75545448  8040264  91% /mnt

As you can see, the wrong mount is removed from the output.

So, if you do anything fancy with bind mounts then you might want to be wary of this as your filesystems may very well disappear from the output of 'df'.

As a work-around I've found that "df -a -x none -x proc -x sysfs" or "df -a -t ext4 -t tmpfs" seems to provide sensible output.

"df -a -x proc -x sysfs" seems the closest match to the previous default behaviour as far as I can tell.

I can feel an alias coming on!

GazL 03-11-2013 06:38 AM

replying to myself to get it off the zero-reply list. ;)

wildwizard 03-11-2013 07:39 AM

I think where they have gone wrong is they are going with the last one instead of the first one.

ie df parses /etc/mtab from top to bottom and each time it hits a duplicate block device it goes with the new mount instead of ignoring the new one and keeping the old one.

GazL 03-11-2013 08:00 AM

Just had a look in the src for df and found this:
Code:

/* Filter mount list by skipping duplicate entries.
  In the case of duplicities - based on to the device number - the mount entry
  with a '/' in its me_devname (i.e. not pseudo name like tmpfs) wins.
  If both have a real devname (e.g. bind mounts), then that with the shorter
  me_mountdir wins.  */

So, they're not acting on order, which I agree would have been a much better idea than having something as arbitrary as the length of the mountpoint decide.
Here:
Code:

root@ws1:~# df
Filesystem                  1K-blocks    Used Available Use% Mounted on
/dev/mapper/rootvg-lvroot    16382888  5847268  9696760  38% /
/dev/mapper/rootvg-lvlocal    83585712 75545448  8040264  91% /local
root@ws1:~# mount -o bind /local /mnt
root@ws1:~# df
Filesystem                  1K-blocks    Used Available Use% Mounted on
/dev/mapper/rootvg-lvroot    16382888  5847268  9696760  38% /
/local                        83585712 75545448  8040264  91% /mnt
root@ws1:~# umount /mnt
root@ws1:~# mount -o bind /local /mnt/tmp
root@ws1:~# df
Filesystem                  1K-blocks    Used Available Use% Mounted on
/dev/mapper/rootvg-lvroot    16382888  5847268  9696760  38% /
/dev/mapper/rootvg-lvlocal    83585712 75545448  8040264  91% /local

... that's just bonkers behaviour. Clearly, they haven't thought this one through fully.


All times are GMT -5. The time now is 04:03 AM.