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

[Zbigniew Jędrzejewski-Szmek]

On Tue, Oct 02, 2012 at 02:00:20AM +0200, Marius Tolzmann wrote:
> 
> Hi..
> 
> On 01.10.2012 20:32, Reindl Harald wrote:
> >
> >>>and how they should do this after the change that there
> >>>is no flag? dispaly a RANDOM line?
> >>
> >>That is a possibility. Based upon that you are only interested
> >>in the device anyway, I conclude the mountpoint is irrelevant
> >
> >that makes preety no sense on a server with > 100 bind-mounts
> >if everytime any of the admins type "df" he sees different
> >mountpoints - this is a computer not a gambling machine
> 
> Can't you just revert the old behavior by removing the symlink and
> just touching /etc/mtab? Or do I miss something? If your system
> depends on stuff like that, then just do it the way you need it..
> It's open source and you can do what ever you want?
> 
> I think systemd will just issue a warning that you may just want to
> ignore. (Or has that changed in the past and systemd enforces this
> and stops working?)
> 
> >and these are basic things which should be considered BEFORE
> >any invasive change and not after the damage is done since
> >more than a year
> 
> Actually for me df always showed every bind mounted mountpoint.
> Since it was recorded in /etc/mtab it also showed which olddir I
> have mounted on which newdir (mount --bind olddir newdir)
> 
> like in
> 
> 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.

> 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.

> Because I personally think displaying /dev/sdb4 as a device in
> /proc/mounts for a bind-mount may in fact be wrong. Because i can't
> use the information displayed there to unmount that mountpoint and
> mount it again? Or can I? I don't think so, because the information
> "which subdirectory (olddir)" was mounted here is not displayed.
> (I did not yet do any research on this topic - that is just what
> came to mind while following this discussion)
> 
> I really think there is some regression after replacing /etc/mtab
> with a symlink. But I also do think symlinking /etc/mtab was a good
> thing to do: to keep /etc/mtab up-to-date.
> 
> IMHO the regression is partially caused by /proc/mounts not showing
> the olddir information but just the device name (/dev/sdXn,
> /dev/mdXn, ..).
> 
> 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.

Zbyszek