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

[Marius Tolzmann]

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.

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)

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

But I think this is in fact a kernel issue and has nothing to do with 
systemd - so sorry for the noise here but hopefully someone here can 
follow my thoughts and cares about fixing/changing this so that systemd 
won't be blamed for this again.. 8)

But at last: I also do not think flaming and crying will help to solve 
any issue.

Thanks and bye marius..