Maybe I do oversee the obious but:
can somebody please explain why rootfs is exposed in /proc/mounts (I do
mean the "rootfs / rootfs rw 0 0" entry) and if there is a good reason
for the exposure?
--
Andreas Steinmetz
On Sat, 26 Oct 2002, Andreas Steinmetz wrote:
> Maybe I do oversee the obious but:
>
> can somebody please explain why rootfs is exposed in /proc/mounts (I do
> mean the "rootfs / rootfs rw 0 0" entry) and if there is a good reason
> for the exposure?
Mostly the fact that it _is_ mounted and special-casing its removal from
/proc/mounts is more PITA than it's worth.
Alexander Viro wrote:
>
> On Sat, 26 Oct 2002, Andreas Steinmetz wrote:
>
>
>>Maybe I do oversee the obious but:
>>
>>can somebody please explain why rootfs is exposed in /proc/mounts (I do
>>mean the "rootfs / rootfs rw 0 0" entry) and if there is a good reason
>>for the exposure?
>
>
> Mostly the fact that it _is_ mounted and special-casing its removal from
> /proc/mounts is more PITA than it's worth.
>
Acceptable but somewhat sad as it confuses e.g. "umount -avt noproc"
which is somewhat standard in shutdown/reboot scripts (using a softlink
from /etc/mtab to /proc/mounts).
Andreas Steinmetz wrote:
> Alexander Viro wrote:
>
>>
>> On Sat, 26 Oct 2002, Andreas Steinmetz wrote:
>>
>>
>>> Maybe I do oversee the obious but:
>>>
>>> can somebody please explain why rootfs is exposed in /proc/mounts (I
>>> do mean the "rootfs / rootfs rw 0 0" entry) and if there is a good
>>> reason for the exposure?
>>
>>
>>
>> Mostly the fact that it _is_ mounted and special-casing its removal from
>> /proc/mounts is more PITA than it's worth.
>>
> Acceptable but somewhat sad as it confuses e.g. "umount -avt noproc"
> which is somewhat standard in shutdown/reboot scripts (using a
> softlink from /etc/mtab to /proc/mounts).
Bug 1 - don't softlink directly to /proc/mounts :) embedded guys
typically do this, and you see why it bites you in the ass :)
Bug 2 - "noproc" clearly does not avoid ramfs mounts, which is rootfs's
filesystem type. And more and more ramfs filesystems will be appearing,
so that should be taken into consideration.
Sounds like userspace slackness to me, and nothing that the kernel guys
need to worry about...
Jeff
Jeff Garzik wrote:
> Andreas Steinmetz wrote:
>
>> Alexander Viro wrote:
>>
>>>
>>> On Sat, 26 Oct 2002, Andreas Steinmetz wrote:
>>>
>>>
>>>> Maybe I do oversee the obious but:
>>>>
>>>> can somebody please explain why rootfs is exposed in /proc/mounts (I
>>>> do mean the "rootfs / rootfs rw 0 0" entry) and if there is a good
>>>> reason for the exposure?
>>>
>>>
>>>
>>>
>>> Mostly the fact that it _is_ mounted and special-casing its removal from
>>> /proc/mounts is more PITA than it's worth.
>>>
>> Acceptable but somewhat sad as it confuses e.g. "umount -avt noproc"
>> which is somewhat standard in shutdown/reboot scripts (using a
>> softlink from /etc/mtab to /proc/mounts).
>
>
>
> Bug 1 - don't softlink directly to /proc/mounts :) embedded guys
> typically do this, and you see why it bites you in the ass :)
>
> Bug 2 - "noproc" clearly does not avoid ramfs mounts, which is rootfs's
> filesystem type. And more and more ramfs filesystems will be appearing,
> so that should be taken into consideration.
>
> Sounds like userspace slackness to me, and nothing that the kernel guys
> need to worry about...
>
Only if there's another method to retrieve all filesystems mounted from
userspace from the kernel. Though this may not be your view of things it
is the only way to ensure that one gets a valid mount list. And as
/proc/mounts is an interface to userspace it is my opinion that in
kernel private mounts that can't be modified from userspace don't need
to be listed there. Not my decision, anyway.
Jeff Garzik wrote:
[...]
>
> Bug 1 - don't softlink directly to /proc/mounts :) embedded guys
> typically do this, and you see why it bites you in the ass :)
>
Jeff, this remembers me on some discussion on LKML we had almost
exactly 2 years ago (look for the thread starting with Message-ID
[email protected])
Do you remember?
My opinion on this issue is still the same:
- Not only "embedded guys" symlink /etc/mtab to /proc/mounts!
We do this for years now on our diskless workstations, because
here our root-fs (and therefore /etc) is mounted readonly and
so there is no way to update a _regular_ "/etc/mtab" file on
a running system.
- /etc should contain only static configuration information.
The table of mounted filesystems is not this kind of data.
It's state information and should live somewhere else.
- the table of mounted filesystems is information which
the kernel must have, anyway. Why maintain a separate
file in userspace?
Comments?
- Andreas
--
Andreas Haumer | mailto:[email protected]
*x Software + Systeme | http://www.xss.co.at/
Karmarschgasse 51/2/20 | Tel: +43-1-6060114-0
A-1100 Vienna, Austria | Fax: +43-1-6060114-71
Hi !
I remember this discussion too, and am also used to symlink mtab to
/proc/mounts. But I also remember some people stating that /proc/mounts doesn't
contain all information (some mount flags, nfs options ...) which may be needed
for a mount -o remount, while mtab contains them.
I too agree that it's non-sense to have both mtab and /proc/mounts. If mounts
isn't usable, why keep it ? At the moment, the only reason why I would abandon
this symlink would be that mounts be removed from /proc entirely ! And I also
agree that mtab shouldn't be under /etc (this is the only file that needs to
be written to). At least, it should be moved to /var/state or something like
that, provided it's available early in the boot stage, but this issue is not a
kernel one anyway.
But at this time, I still think that a symlink to /proc/mounts is the safest
solution in embedded or diskless situations, because even if we cannot update
it for the very first mounts, at least it will be correct when /proc is
mounted.
May be we should just accept this case as a common one, and update tools
(mount, umount, df, ?) to be able to use both mtab and /proc/mounts, and simply
ignore any rootfs entry.
Just my 0.02 euros.
Willy
symlinks directly to /proc/mounts is fine with me -- just don't expect
any sympathy when userspace tools don't handle things like $subject. :)
The answer will be "fix the userspace tools" not "add special case code
to the kernel" :)
Jeff
On Sun, Oct 27, 2002 at 10:02:31AM -0500, Jeff Garzik wrote:
> symlinks directly to /proc/mounts is fine with me -- just don't expect
> any sympathy when userspace tools don't handle things like $subject. :)
> The answer will be "fix the userspace tools" not "add special case code
> to the kernel" :)
well, better link to /proc/self/mounts directly, that's where /proc/mounts
links to. That's another reason why the /etc/mtab-concept is broken:
you might have very different mounts in different processes.
On Sun, Oct 27, 2002 at 12:18:56PM +0100, Willy Tarreau wrote:
> And I also
> agree that mtab shouldn't be under /etc (this is the only file that needs to
> be written to). At least, it should be moved to /var/state or something like
> that, provided it's available early in the boot stage,
I was just looking at these things I found few more such files in
/etc. Like /etc/adjtime, /etc/mrtg/<something> and /etc/.aumixrc.
I consider all of these user-space bugs. There are also /etc/passwd
and /etc/shadow which will be written to if you are changing
passwords while not using something like NIS. This is, in a sense,
a harder case but one can live with that.
Michal
On Sun, 2002-10-27 at 16:09, Christoph Hellwig wrote:
> you might have very different mounts in different processes.
You can ?? apart from chroot that can make things interesting how do
you do this?
On Mon, Oct 28, 2002 at 01:03:28AM +0100, Kenneth Johansson wrote:
> On Sun, 2002-10-27 at 16:09, Christoph Hellwig wrote:
> > you might have very different mounts in different processes.
>
> You can ?? apart from chroot that can make things interesting how do
> you do this?
clone(..., CLONE_NEWNS, ...)
After that subsequent namespace operations will only affect your process
and it's child processes.
On Sunday 27 October 2002 18:18, Christoph Hellwig wrote:
> On Mon, Oct 28, 2002 at 01:03:28AM +0100, Kenneth Johansson wrote:
> > On Sun, 2002-10-27 at 16:09, Christoph Hellwig wrote:
> > > you might have very different mounts in different processes.
> >
> > You can ?? apart from chroot that can make things interesting how do
> > you do this?
>
> clone(..., CLONE_NEWNS, ...)
>
> After that subsequent namespace operations will only affect your process
> and it's child processes.
Cool.
Question: if those processes mount something and then exit, does that
something get unmounted automatically or is this a mount point leak?
Rob
--
http://penguicon.sf.net - Terry Pratchett, Eric Raymond, Pete Abrams, Illiad,
CmdrTaco, liquid nitrogen ice cream, and caffienated jello. Well why not?
Willy Tarreau wrote:
>
> Hi !
>
> I remember this discussion too, and am also used to symlink mtab to
> /proc/mounts. But I also remember some people stating that /proc/mounts doesn't
> contain all information (some mount flags, nfs options ...) which may be needed
> for a mount -o remount, while mtab contains them.
There seems to be two types of information in mtab, which is missing in
/proc/mounts. First of all the first field of mtab is not always the name
of a blockdevice. If it is a bindmount, this field will contain the name
of the directory rather than the device, however this confuses some
startupscripts, so having the device here might actually be better.
If the mount was done using the loop option, this field will contain the
name of the backing file rather than the name of the loopback device. In
the output from df, the name of the backing file will be more informative
than the name of the loopback device, so I don't want to change that. But
since a loopback device can also be mounted by manually using the losetup
command, I would prefer another way to get the name of the backing file,
that will work in both cases.
The options available in mtab but not in /proc/mounts, I would like to
add to /proc/mounts. This could just be a string writable by the mount
program. I don't think this should be anything fancy, just that any write
to /proc/mounts should find the coresponding mount and update the string.
>
> I too agree that it's non-sense to have both mtab and /proc/mounts. If mounts
> isn't usable, why keep it ? At the moment, the only reason why I would abandon
> this symlink would be that mounts be removed from /proc entirely ! And I also
> agree that mtab shouldn't be under /etc (this is the only file that needs to
> be written to). At least, it should be moved to /var/state or something like
> that, provided it's available early in the boot stage, but this issue is not a
> kernel one anyway.
If the /etc/mtab file should exist at all it should at least be on a
ramfs so we won't have to have the root mounted readwrite to update it.
I have moved by mtab file to /etc/mtab.d/mtab and mount a ramfs on
/etc/mtab.d. On boot I first mount /proc and /etc/mtab.d, then I create
the mtab file from /proc/mounts. This is not an optimal solution, but I
think it works better than having mtab on the root fs.
>
> May be we should just accept this case as a common one, and update tools
> (mount, umount, df, ?) to be able to use both mtab and /proc/mounts, and simply
> ignore any rootfs entry.
The optimal solution of the problem will include an update of the tools,
and probably also the kernel.
--
Kasper Dupont -- der bruger for meget tid p? usenet.
For sending spam use mailto:[email protected]
Don't do this at home kids: touch -- -rf
> > > On Sun, 2002-10-27 at 16:09, Christoph Hellwig wrote:
> > clone(..., CLONE_NEWNS, ...)
> >
> > After that subsequent namespace operations will only affect your process
> > and it's child processes.
>
> Cool.
>
> Question: if those processes mount something and then exit, does that
> something get unmounted automatically or is this a mount point leak?
Both namespaces and vfsmounts are refcounted and garbage-collected
if their useage counts hits zero, so there will be no leak.