while after the breakage in F15 this was fine with F18 "df" in F19 is again too stupid to show the real mountpoint instead a random bind-mount coreutils-8.21-12.fc19.x86_64 [root@testserver:~]$ /usr/bin/df -hT --exclude-type=tmpfs --exclude-type=devtmpfs Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf /dev/sdb1 ext4 12G 2,6G 9,2G 22% / /dev/sda1 ext4 189M 33M 153M 18% /boot /dev/sdc1 ext4 30G 4,3G 26G 15% /tmp _____________________________________ /dev/sdc1 is for sure *not* /tmp hence there is no logic at all display the thris bind-mount UUID=bb7dfa33-8d31-496c-99a9-a1978eef98ec /Volumes/dune ext4 defaults,commit=45,inode_readahead_blks=16,noatime,nodiratime 0 1 /Volumes/dune/www-servers/cms /usr/local/sftp-homes/flow/cms none bind /Volumes/dune/builduser /home/builduser none bind /Volumes/dune/.tmp /tmp none bind /Volumes/dune/.tmp /var/tmp none bind /Volumes/dune/buildserver/autotest /Volumes/dune/www-servers/autotest none bind
Ondrej, can you please take a look on this deduplication? Harald, would it be possible to show us your /proc/mounts (which gets symlinked to /etc/mtab and then de-duplicated by df algorithm)?
here it is you should use the *first* one in doubt which is "/Volumes/dune" and the real mount-point referred by the bind-mounts later ____________________________________________ rootfs / rootfs rw 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 devtmpfs /dev devtmpfs rw,nosuid,size=1568072k,nr_inodes=392018,mode=755 0 0 securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0 tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct,cpu 0 0 cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0 /dev/sdb1 / ext4 rw,noatime,nodiratime,commit=45,inode_readahead_blks=16 0 0 hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0 mqueue /dev/mqueue mqueue rw,relatime 0 0 debugfs /sys/kernel/debug debugfs rw,relatime 0 0 systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=36,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 configfs /sys/kernel/config configfs rw,relatime 0 0 tmpfs /var/www/sessiondata tmpfs rw,noatime,nodiratime,size=32768k 0 0 /dev/sda1 /boot ext4 rw,noatime,nodiratime,commit=45,inode_readahead_blks=16 0 0 /dev/sdc1 /Volumes/dune ext4 rw,noatime,nodiratime,commit=45,inode_readahead_blks=16 0 0 /dev/sdc1 /Volumes/dune/www-servers/autotest ext4 rw,noatime,nodiratime,commit=45,inode_readahead_blks=16 0 0 /dev/sdc1 /var/tmp ext4 rw,noatime,nodiratime,commit=45,inode_readahead_blks=16 0 0 /dev/sdc1 /tmp ext4 rw,noatime,nodiratime,commit=45,inode_readahead_blks=16 0 0 /dev/sdc1 /home/builduser ext4 rw,noatime,nodiratime,commit=45,inode_readahead_blks=16 0 0 /dev/sdc1 /usr/local/sftp-homes/flow/cms ext4 rw,noatime,nodiratime,commit=45,inode_readahead_blks=16 0 0
"First one" was the first implementation... many users complained. Therefore the "shortest" was chosen... we'll see, let's wait for Ondrej's opinion/proposal, how to resolve this properly... bad, bad /proc/mounts (/etc/mtab was much more predictable ;) )
> /etc/mtab was much more predictable i know that and i hate this change since F15 well, there may have been bugs and problems with mtab but before they got fixed i had none of them over years on more than 20 machines - so i want have the bugs back from the last decades :-)
The /proc/mounts above does suggest that /Volumes/dune/.tmp is backed by /dev/sdc1. df would need to get further info. I notice that stat.c has find_bind_mount() which may be useful? What's the output from findmnt --df
yes it is /dev/sdc but since /dev/sdc1 is mounted by UUID i want to see /Voldumes/dune in the df-output and not a *random* bind-mount and this is a ongoing problem since 2011 [root@testserver:~]$ findmnt --df SOURCE FSTYPE SIZE USED AVAIL USE% TARGET devtmpfs devtmpfs 1,5G 0 1,5G 0% /dev tmpfs tmpfs 1,5G 0 1,5G 0% /dev/shm tmpfs tmpfs 1,5G 2,3M 1,5G 0% /run tmpfs tmpfs 1,5G 0 1,5G 0% /sys/fs/cgroup /dev/sdb1 ext4 11,7G 2,5G 9,2G 22% / tmpfs tmpfs 32M 0 32M 0% /var/www/sessiondata /dev/sdc1 ext4 29,4G 4,3G 25,1G 14% /Volumes/dune /dev/sda1 ext4 188,8M 32,3M 152,6M 17% /boot /dev/sdc1[/buildserver/autotest] ext4 29,4G 4,3G 25,1G 14% /Volumes/dune/www-servers/autotest /dev/sdc1[/.tmp] ext4 29,4G 4,3G 25,1G 14% /var/tmp /dev/sdc1[/.tmp] ext4 29,4G 4,3G 25,1G 14% /tmp /dev/sdc1[/builduser] ext4 29,4G 4,3G 25,1G 14% /home/builduser /dev/sdc1[/www-servers/cms] ext4 29,4G 4,3G 25,1G 14% /usr/local/sftp-homes/flow/cms
Yes, find_bind_mount() looks promising; if it proves so, I'd like to add it to gnulib's mountlist.c.
So since /dev/sdc1 does in fact back /tmp here and is the base device for the corresponding file system then I'm not sure there is an issue here. df is supposed to show the lowest level backing device for the file system
> So since /dev/sdc1 does in fact back /tmp here and is the base device *where* is /tmp the base device? *this* is the base device and not a random bind-mount period UUID=bb7dfa33-8d31-496c-99a9-a1978eef98ec /Volumes/dune
> So since /dev/sdc1 does in fact back /tmp here and is the base device even the output of "findmnt --df" shows /dev/sdc1 ext4 29,4G 4,3G 25,1G 14% /Volumes/dune /dev/sdc1[/.tmp] ext4 29,4G 4,3G 25,1G 14% /tmp so guess what the base device is * /dev/sdc and *nothing* else in the line * a random line from the middle with the [/.tmp] bind-folder
can someone revert this crap to the F18 behavior? i really have enough of all this stupidity with "df" over years and no my data partition is *not* mounted on /tmp /tmp is a bind-mount as well as &var/tmp and others and it can't be really that difficult to use the *first* mountpint for a device in the output [root@srv-rhsoft:~]$ df -hT --exclude-type=tmpfs --exclude-type=devtmpfs Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf /dev/md1 ext4 29G 5,9G 23G 21% / /dev/md0 ext4 477M 34M 439M 8% /boot /dev/md2 ext4 3,6T 1,8T 1,9T 49% /tmp ___________________________ each skript-kiddie is able to determine from this "findmnt --df" output that /dev/md2 is mounted on /mnt/data and !!coreutils!! are not? /dev/md2 ext4 3,6T 1,7T 1,9T 48% /mnt/data /dev/md2[/www/thelounge.net] ext4 3,6T 1,7T 1,9T 48% /Volumes/dune/www-servers /dev/md2[/.tmp] ext4 3,6T 1,7T 1,9T 48% /var/tmp /dev/md2[/.tmp] ext4 3,6T 1,7T 1,9T 48% /tmp /dev/md2[/home] ext4 3,6T 1,7T 1,9T 48% /home
and BTW "df" seems to be the only command too stupid for this or how would someone explain that the output of any other command clearly shows the real mountpoint? [root@srv-rhsoft:~]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1,8T 0 disk ├─sda1 8:1 0 500M 0 part │ └─md0 9:0 0 500M 0 raid1 /boot ├─sda2 8:2 0 14,7G 0 part │ └─md1 9:1 0 29,3G 0 raid10 / └─sda3 8:3 0 1,8T 0 part └─md2 9:2 0 3,6T 0 raid10 /mnt/data sdb 8:16 0 1,8T 0 disk ├─sdb1 8:17 0 500M 0 part │ └─md0 9:0 0 500M 0 raid1 /boot ├─sdb2 8:18 0 14,7G 0 part │ └─md1 9:1 0 29,3G 0 raid10 / └─sdb3 8:19 0 1,8T 0 part └─md2 9:2 0 3,6T 0 raid10 /mnt/data sdc 8:32 0 1,8T 0 disk ├─sdc1 8:33 0 500M 0 part │ └─md0 9:0 0 500M 0 raid1 /boot ├─sdc2 8:34 0 14,7G 0 part │ └─md1 9:1 0 29,3G 0 raid10 / └─sdc3 8:35 0 1,8T 0 part └─md2 9:2 0 3,6T 0 raid10 /mnt/data sdd 8:48 0 1,8T 0 disk ├─sdd1 8:49 0 500M 0 part │ └─md0 9:0 0 500M 0 raid1 /boot ├─sdd2 8:50 0 14,7G 0 part │ └─md1 9:1 0 29,3G 0 raid10 / └─sdd3 8:51 0 1,8T 0 part └─md2 9:2 0 3,6T 0 raid10 /mnt/data [root@srv-rhsoft:~]$ df Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf /dev/md1 ext4 29G 5,9G 23G 21% / /dev/md0 ext4 477M 34M 439M 8% /boot /dev/md2 ext4 3,6T 1,8T 1,9T 50% /tmp
for the one which can't read the line with *no* [ in the second column is the right one [root@srv-rhsoft:~]$ findmnt | grep md2 ├─/mnt/data /dev/md2 ext4 rw,nosuid,noatime,nodiratime,commit=45,stripe=256,inode_readahead_blks=256 │ ├─/mnt/data/www/thelounge.net/phpincludes /dev/md2[/www/phpincludes] ext4 rw,nosuid,noatime,nodiratime,commit=45,stripe=256,inode_readahead_blks=256 ├─/Volumes/dune/www-servers /dev/md2[/www/thelounge.net] ext4 rw,nosuid,noatime,nodiratime,commit=45,stripe=256,inode_readahead_blks=256 │ └─/Volumes/dune/www-servers/phpincludes /dev/md2[/www/phpincludes] ext4 rw,nosuid,noatime,nodiratime,commit=45,stripe=256,inode_readahead_blks=256 ├─/var/tmp /dev/md2[/.tmp] ext4 rw,nosuid,noatime,nodiratime,commit=45,stripe=256,inode_readahead_blks=256 ├─/tmp /dev/md2[/.tmp] ext4 rw,nosuid,noatime,nodiratime,commit=45,stripe=256,inode_readahead_blks=256 ├─/home /dev/md2[/home] ext4 rw,nosuid,noatime,nodiratime,commit=45,stripe=256,inode_readahead_blks=256
the same in RHEL7-Beta :-( https://bugzilla.redhat.com/show_bug.cgi?id=1042840
Currently, there is no way how to determine (exactly) that mountpoint is bind-mounted: https://bugzilla.redhat.com/show_bug.cgi?id=920806#c18 There are only heuristics, such as the shortest path. I agree that this can be confusing (like in your case). I can imagine that the algorithm can be improved by using root of the mount from /proc/self/mountinfo, as shown in findmnt output, but this is still a heuristic (e.g. prefer /dev/sdc1 over /dev/sdc1[/.tmp]). One can still bind mount root of the mount.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
it's ridiculous that bugzappe closes this bug reported for F19 while it is still in F20/F21 present [root@testserver:~]$ df Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf /dev/sdb1 ext4 12G 3,2G 8,6G 28% / /dev/sda1 ext2 189M 35M 154M 19% /boot /dev/sdc1 ext4 30G 4,6G 25G 16% /tmp [root@testserver:~]$ cat /etc/fstab UUID=6f7807bd-a508-44c7-9e72-651f82b6ad6c /boot ext2 defaults 0 1 UUID=9b4bf81a-5b1e-4922-b0d1-e6b65e9b61f9 / ext4 defaults,commit=25,inode_readahead_blks=16,noatime,nodiratime 0 1 UUID=bb7dfa33-8d31-496c-99a9-a1978eef98ec /Volumes/dune ext4 defaults,commit=25,inode_readahead_blks=16,noatime,nodiratime 0 1 /Volumes/dune/www-servers/cms /usr/local/sftp-homes/flow/cms none bind /Volumes/dune/builduser /home/builduser none bind /Volumes/dune/.tmp /tmp none bind /Volumes/dune/.tmp /var/tmp none bind /Volumes/dune/buildserver/autotest /Volumes/dune/www-servers/autotest none bind [root@testserver:~]$ uname -r 3.18.7-200.fc21.x86_64
well, and that is the joke of the day while it is pretty clear from findmnt output what is the real mount-point [root@rh:~]$ /bin/df -hT | grep ext4 /dev/md1 ext4 29G 6,3G 23G 22% / /dev/md0 ext4 485M 35M 446M 8% /boot /dev/md2 ext4 3,6T 694G 2,9T 20% /tmp [root@rh:~]$ /bin/df -hT /dev/md2 Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf /dev/md2 ext4 3,6T 695G 2,9T 20% /mnt/data/www/thelounge.net/phpincludes [root@rh:~]$ findmnt | grep md2 ├─/mnt/data /dev/md2 ext4 rw,nosuid,noatime,nodiratime,commit=35,stripe=256,inode_readahead_blks=128 │ └─/mnt/data/www/thelounge.net/phpincludes /dev/md2[/www/phpincludes] ext4 rw,nosuid,noatime,nodiratime,commit=35,stripe=256,inode_readahead_blks=128 ├─/Volumes/dune/www-servers /dev/md2[/www/thelounge.net] ext4 rw,nosuid,noatime,nodiratime,commit=35,stripe=256,inode_readahead_blks=128 │ └─/Volumes/dune/www-servers/phpincludes /dev/md2[/www/phpincludes] ext4 rw,nosuid,noatime,nodiratime,commit=35,stripe=256,inode_readahead_blks=128 ├─/var/cache/yum /dev/md2[/.yumcache] ext4 rw,nosuid,noatime,nodiratime,commit=35,stripe=256,inode_readahead_blks=128 ├─/var/tmp /dev/md2[/.tmp] ext4 rw,nosuid,noatime,nodiratime,commit=35,stripe=256,inode_readahead_blks=128 ├─/tmp /dev/md2[/.tmp] ext4 rw,nosuid,noatime,nodiratime,commit=35,stripe=256,inode_readahead_blks=128 └─/home /dev/md2[/home] ext4 rw,nosuid,noatime,nodiratime,commit=35,stripe=256,inode_readahead_blks=128
congratulations, starting with F15 and later fixed for a short time we suffer now from this FIVE YEARS and then people ask why users get a insulting and frustrating tone? frankly, that goes even so far now that a bind-mount made long after boot is the one which appears in "df" instead the real mount point and giving that most on most machines where /tmp ist a bind-mount to the data-disk it's really annyoing all day long
Harald, I can see your frustration. Many things improved in df since the F15 - still not perfect, still not on par with the previous situation, where util-linux maintained /etc/mtab itself. Unfortunately - this doesn't have any good solution. If you have perfect solution, feel free to explain it. Several people already tried to make it better... we should definitely continue with improvements, but without clear (and generic enough) improvements it will take long time to improve this situation further.
just read https://bugzilla.redhat.com/show_bug.cgi?id=1001092#c11 and https://bugzilla.redhat.com/show_bug.cgi?id=1001092#c12 - if that's not enough to find a good solution then i need to call some upstream developers names!
Harald, could you please try it with coreutils-8.24-6.fc23 or newer?
the same behavior [root@rh:~]$ df Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf /dev/md1 ext4 29G 6,7G 23G 24% / /dev/md0 ext4 485M 31M 451M 7% /boot /dev/md2 ext4 3,6T 692G 2,9T 20% /tmp [root@rh:~]$ rpm -q coreutils coreutils-8.24-6.fc23.x86_64 [root@srv-rhsoft:~]$ findmnt | grep md2 ??/mnt/data /dev/md2 ext4 rw,nosuid,relatime,lazytime,commit=60,stripe=256,inode_readahead_blks=128 ? ??/mnt/data/www/thelounge.net/phpincludes /dev/md2[/www/phpincludes] ext4 rw,nosuid,relatime,lazytime,commit=60,stripe=256,inode_readahead_blks=128 ??/tmp /dev/md2[/.tmp] ext4 rw,nosuid,relatime,lazytime,commit=60,stripe=256,inode_readahead_blks=128 ??/var/tmp /dev/md2[/.tmp] ext4 rw,nosuid,relatime,lazytime,commit=60,stripe=256,inode_readahead_blks=128 ??/home /dev/md2[/home] ext4 rw,nosuid,relatime,lazytime,commit=60,stripe=256,inode_readahead_blks=128 ??/Volumes/dune/www-servers /dev/md2[/www/thelounge.net] ext4 rw,nosuid,relatime,lazytime,commit=60,stripe=256,inode_readahead_blks=128 ??/Volumes/dune/www-servers/phpincludes /dev/md2[/www/phpincludes] ext4 rw,nosuid,relatime,lazytime,commit=60,stripe=256,inode_readahead_blks=128
I believe the following upstream commit will fix it: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3babaf83
coreutils-8.24-7.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-5f4c303213
that looks now as expected - thank you! [root@rh:/downloads]$ df Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf /dev/md1 ext4 29G 6,7G 23G 24% / /dev/md0 ext4 485M 31M 451M 7% /boot /dev/md2 ext4 3,6T 693G 2,9T 20% /tmp [root@rh:/downloads]$ rpm -Uvh coreutils-8.24-7.fc23.x86_64.rpm [root@rh:/downloads]$ df Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf /dev/md1 ext4 29G 6,7G 23G 24% / /dev/md0 ext4 485M 31M 451M 7% /boot /dev/md2 ext4 3,6T 693G 2,9T 20% /mnt/dat
Perfect. Thanks for the confirmation and sorry for the delays on this!
coreutils-8.24-7.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-5f4c303213
coreutils-8.24-7.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.