[systemd-devel] when will mount / df get fixed?

Marius Tolzmann tolzmann at molgen.mpg.de
Tue Oct 2 02:24:58 PDT 2012



Hi..

On 10/02/12 10:11, Zbigniew Jędrzejewski-Szmek wrote:

>>
>> filesystem     size mounted on
>> /mnt/whatever  xxx  /wherever
>>
>> now instead displaying it as /mnt/whatever it just displays as /dev/sdb3 ..
>>
>> Which is in fact not nice, but hey, it works.
> 
> This is not as nice, but actually more correct. If the original
> mountpoint is unmounted, which is certainly possible, than the old
> line with /mnt/whatever is not true anymore. The line with
> /dev/whatever is still correct.

That's true. But as long as '/' of the same device is also mounted it
may be possible to display it that way. So the mount order is not important.

>> BTW Is there a way to see what olddir was bind mounted on which
>> newdir with /etc/mtab being a symlink to /proc(/self)/mounts? Does
>> the kernel keep track of this information at all? Should it at all
>> keep track of it? And if not, why not? Is this information present
>> in some kernel structure which is just not exported via procfs?
>> Hey, Kernel guys, please help 8)
> $ sudo mount --bind /usr/share/info /tmp/info
> $ findmnt
> ...
> └─/tmp/info /dev/mapper/root[/usr/share/info] ext4 rw,noatime,err
> 
> So, the answer is yes. The data comes from /proc/self/mountinfo.

Oh I missed that... thank you. I actually looked at /proc/self/mountinfo
but misinterpreted the output. And my findmnt seems to be out of date,
because it does not show this information. ;)

>> Because it is not /dev/sda1 which is mounted as /. It is / of (the
>> filesystem on) /dev/sda1 which is mounted as /. And it may be
>> /tmp/abc of /dev/sda1 which is mounted as /home/abc/tmp (and not
>> just /dev/sda1 mounted as /home/abc/tmp).
> The original mountpoint is irrelevant. What you say, that the / of the
> filesystem is mounted, is true. But by convention, when mounting the /
> of the filesystem, mount shows it as if the device was mounted. This
> makes sense because it is certainly the most common case.

I agree, it is irrelevant if you mount the root (/). ;)

But to focus again to the original problem, where df does not work
(because systemd is evil and broke it ;) )

I think (given your information) that it may be possible to fix the
original issue where a symlinked mtab pollutes df output just by using
the information provided by the kernel itself and not depending on some
maybe-out-of-date-/etc/mtab.

"If no file name is given, the space available on all currently mounted
file systems is shown." (from df(1)). If this is intended, then it was
broken before, because it only showed filesystems recorded in /etc/mtab
and not all mounted filesystems 8).

So maybe neither (symlinked) /etc/mtab nor df needs to be fixed. There
is just a tool missing, showing only the diskusage / available space of
all currently used/mounted block devices (only once)? (Or a filter in
df: df -b or df --block-devices)

..or whatever.. but it is not a systemd issue at all and I think there
is no need to continue the flamewar, since all the information needed to
fix this, is available under /proc ;)

regards,
	marius..

-- 
Dipl.-Inf. Marius Tolzmann <marius.tolzmann at molgen.mpg.de>
----------------------------------.------------------------------
MPI f. molekulare Genetik         |
Ihnestrasse 63-73, D-14195 Berlin |   ==> MarIuX GNU/Linux <==
Phone: +49 (0)30 8413 1709        |
----------------------------------^------------------------------
God put me on earth to accomplish a certain number of things.
Right now I am so far behind..
   ..I will never die.         <by calvin from calvin&hobbes ;)>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4572 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20121002/0712cd2d/attachment.bin>


More information about the systemd-devel mailing list