Bug 1042840
| Summary: | wrong handling of bind-mount with "df" | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Harald Reindl <h.reindl> |
| Component: | coreutils | Assignee: | Kamil Dudka <kdudka> |
| Status: | CLOSED ERRATA | QA Contact: | Radka Brychtova <rskvaril> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.0 | CC: | ddouwsma, gsierohu, jshivers, kdudka, mattdm, peljasz, rskvaril, yzheng |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | coreutils-8.22-24.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-08-06 13:06:19 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1001092 | ||
| Bug Blocks: | 1400024, 1400961, 1420851, 1472751, 1668137 | ||
|
Description
Harald Reindl
2013-12-13 13:57:54 UTC
Because noone so far came with some solution suitable for all situations... /etc/mtab is what df uses and as it is symlink to /proc/mounts , this is the only information df has. There were several approaches to this problem, none of them is perfect. it was not a symlink for about 15 years so maybe such changes should be introduced if they are ready even in PHP i could write within 10 minutes a script parsing the outputs starting in https://bugzilla.redhat.com/show_bug.cgi?id=1001092#c11 but sadly "coreutils" are not written in PHP so i can't fix them I haven't introduced the mtab symlink - you know who did... but it was done, so not much to do now. Coreutils are written to be portable ... this is the main reason why we can't do hacks for Fedora only. Some ugly hack can be written in several minutes, but it will work only on all machines (setups may differ)... and most importantly - most probably will not be acceptable by upstream. When we had duplicates, people complained, for shortest one device name people complain, first come first serve - people complain - I really don't see any magic solution working for everyone. The only way would be to write new, linux specific part in gnulib mountlist module, probably inspired by util-linux submounts solution - this way can be identified the main mount. No way how to get the information from /proc/mounts file. As util-linux differ from coreutils style a bit, it could be quite difficult task. > When we had duplicates, people complained because it is unacceptable on a server with some hundret bind-mounts becauseo one is using openssh's sftp-chroot to replace FTP, i was th eone complaining > for shortest one device name people complain because it is wrong > first come first serve - people complain who complains here? the first one *non bind-mount* is the primary device in case of "df" == disk free i want this one, only once not a random bind-mount *using* that one in /etc/fstab treating my /mnt/data as /tmp in df-output is questionable to say it polite sicne /tmp is a bind-mount to /mnt/data/.tmp and i am for sure not the only person acting this way to prevent from TmpOnTmpfs in case of machines with no need for a dediacted /tmp-partition and not want it on rootfs for well known reasons > Coreutils are written to be portable that's fine - but IMHO the job of a *distribution* is to give a useful behavior for it's core commands - in Fedora 18 this was done right and from Fedora 19/20 to RHEL7 it is broken again, well not that broken as in Fedora 15 with listing all bind-mounts but still a step backwards from F18 behavior > I haven't introduced the mtab symlink - you know who did
kernel upstream, but i am pretty sure they did not expect that userland-software like "df" is rocket science not able to cope with it beause all needed system informations are present and kernel-upstream has it's focus on Linux
(In reply to Harald Reindl from comment #5) > who complains here? > > the first one *non bind-mount* is the primary device > in case of "df" == disk free i want this one, only once > not a random bind-mount *using* that one in /etc/fstab https://bugzilla.redhat.com/show_bug.cgi?id=709351#c31 There started the way of "first come, first serve" - which worked for the bind mounts quite well, but had other issues... I meant the way to "silicon heaven"... later on, on upstream mailing list, the current approach was chosen as the "best one". Still - it doesn't work correctly for some types of bindmounts... This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. well, can we have this fix for Fedora too where this issue exists for years now with a short timeframe where it was fixed /dev/md2 is *not* /tmp /mnt/data/.tmp /tmp none bind /mnt/data/.tmp /var/tmp none bind Filesystem Type Size Used Avail Use% Mounted on /dev/md1 ext4 29G 6.5G 23G 23% / /dev/md0 ext4 485M 37M 444M 8% /boot /dev/md2 ext4 3.6T 2.1T 1.5T 60% /tmp The comment above is incorrect. The correct version is bellow. I'm sorry for any inconvenience. --------------------------------------------------------------- This request was NOT resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you need to escalate this bug. Note this is now fixed in Fedora. See bug #1001092 for details. *** Bug 1261032 has been marked as a duplicate of this bug. *** *** Bug 1450229 has been marked as a duplicate of this bug. *** *** Bug 1650045 has been marked as a duplicate of this bug. *** Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:2217 |