About /etc/mtab and /proc/mounts

About /etc/mtab and /proc/mounts

[DervishD]

    Hi all :))

    I would like to know if adding the bits of information that
/etc/mtab has and /proc/mount doesn't needs a lot of work. The
problem here is that /etc/mtab, although traditional, does not make
sense in systems where /etc is mounted read-only. Usually, the only
reason for mounting it read-write is the mtab...

    Well, nowadays is very usual to see systems where /etc/mtab is
just a symlink to /proc/mounts, but then you lose some information.
That is, you can live without that info, but if it can be easily
added I think that it would worth the effort.

    Unfortunately, some of this information is obtained from
/etc/fstab but IMHO the kernel has that info too in some table, I
suppose...

    Well, if someone familiar with this part of the kernel gives me
the information I think I can write the code for the 'extra'
information ;))

    I give an example of this extra information:

    in /etc/mtab we have:
        pts /dev/pts devpts rw,gid=5,mode=620 0 0

    in /proc/mounts we have:
        pts /dev/pts devpts rw 0 0

    Other filesystems, as tmpfs, has the size information, for
example, etc...

    Thanks in advance.
    Raúl

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

DervishD wrote:
> 
>     Hi all :))
> 
>     I would like to know if adding the bits of information that
> /etc/mtab has and /proc/mount doesn't needs a lot of work. The
> problem here is that /etc/mtab, although traditional, does not make
> sense in systems where /etc is mounted read-only. Usually, the only
> reason for mounting it read-write is the mtab...

We are also discussing that from time to time on c.o.l.d.system.
You could take a look on the thread starting with
<news:3E5A343D.186F3074@daimi.au.dk>

I don't think you can put all the information from /etc/mtab
into /proc/mounts without breaking compatibility. So perhaps a
new /proc/mtab would be a better aproach?

However some of the fields written to mtab by mount is not
easilly known by the kernel, so perhaps we could have mount
write them to /proc/mtab.

A simpler solution, that does not require changes to the kernel
would be to just move mtab to a more apropriate location. My
suggestion would be to change it from /etc/mtab to /mtab.d/mtab.
Then you could mount a tmpfs filesystem on /mtab.d. Or by making
/mtab.d a symlink, you can get the mtab file whereever you want,
including /etc.

> 
>     Well, nowadays is very usual to see systems where /etc/mtab is
> just a symlink to /proc/mounts, but then you lose some information.
> That is, you can live without that info, but if it can be easily
> added I think that it would worth the effort.

I agree with that. Some of it may be easy, but not all of it.

> 
>     Unfortunately, some of this information is obtained from
> /etc/fstab but IMHO the kernel has that info too in some table, I
> suppose...
> 
>     Well, if someone familiar with this part of the kernel gives me
> the information I think I can write the code for the 'extra'
> information ;))
> 
>     I give an example of this extra information:
> 
>     in /etc/mtab we have:
>         pts /dev/pts devpts rw,gid=5,mode=620 0 0
> 
>     in /proc/mounts we have:
>         pts /dev/pts devpts rw 0 0
> 
>     Other filesystems, as tmpfs, has the size information, for
> example, etc...

Some more interesting cases are loopback mounts and bind mounts,
in which case the device field is completely different. But the
filesystem specific options are not trivial either. The fact that
you can use a remount to change some of the options but not all
of them means that only the filesystem itself can tell you what
exactly the options are right now. (And since I remember remount
bugs in tmpfs in early 2.4 kernels, it is not going to get easier
to put more requirements on the filesystem.)

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[Miquel van Smoorenburg]

In article <3E5C8682.F5929A04@daimi.au.dk>,
Kasper Dupont  <kasperd@daimi.au.dk> wrote:
>A simpler solution, that does not require changes to the kernel
>would be to just move mtab to a more apropriate location. My
>suggestion would be to change it from /etc/mtab to /mtab.d/mtab.
>Then you could mount a tmpfs filesystem on /mtab.d. Or by making
>/mtab.d a symlink, you can get the mtab file whereever you want,
>including /etc.

/dev/shm ? Supposed to be there on many systems anyway. Fix
'mount' and 'umount' so that if they see /etc/mtab is a symlink,
they follow it and create the temp files etc in the destination
directory of the link instead of in /etc. Then
ln -sf /dev/shm/mtab /etc/mtab et voila

I've been thinking of doing this for Debian.

Mike.
-- 
Anyone who is capable of getting themselves made President should
on no account be allowed to do the job -- Douglas Adams.

Re: About /etc/mtab and /proc/mounts

[Olaf Dietsche]

miquels@cistron-office.nl (Miquel van Smoorenburg) writes:

> In article <3E5C8682.F5929A04@daimi.au.dk>,
> Kasper Dupont  <kasperd@daimi.au.dk> wrote:
>>A simpler solution, that does not require changes to the kernel
>>would be to just move mtab to a more apropriate location. My
>>suggestion would be to change it from /etc/mtab to /mtab.d/mtab.
>>Then you could mount a tmpfs filesystem on /mtab.d. Or by making
>>/mtab.d a symlink, you can get the mtab file whereever you want,
>>including /etc.
>
> /dev/shm ? Supposed to be there on many systems anyway. Fix
> 'mount' and 'umount' so that if they see /etc/mtab is a symlink,
> they follow it and create the temp files etc in the destination
> directory of the link instead of in /etc. Then
> ln -sf /dev/shm/mtab /etc/mtab et voila

I thought, this is what /var is for. So, /var/run, /var/lib/misc or
/var/etc might be more appropriate?

OTOH, "ln -s /proc/mounts /etc/mtab" works just fine here.

Regards, Olaf.

Re: About /etc/mtab and /proc/mounts

[Måns Rullgård]

Olaf Dietsche <olaf.dietsche@t-online.de> writes:

> >>A simpler solution, that does not require changes to the kernel
> >>would be to just move mtab to a more apropriate location. My
> >>suggestion would be to change it from /etc/mtab to /mtab.d/mtab.
> >>Then you could mount a tmpfs filesystem on /mtab.d. Or by making
> >>/mtab.d a symlink, you can get the mtab file whereever you want,
> >>including /etc.
> >
> > /dev/shm ? Supposed to be there on many systems anyway. Fix
> > 'mount' and 'umount' so that if they see /etc/mtab is a symlink,
> > they follow it and create the temp files etc in the destination
> > directory of the link instead of in /etc. Then
> > ln -sf /dev/shm/mtab /etc/mtab et voila
> 
> I thought, this is what /var is for. So, /var/run, /var/lib/misc or
> /var/etc might be more appropriate?

What if /var is mounted separately?

> OTOH, "ln -s /proc/mounts /etc/mtab" works just fine here.

The only problem I have with that is that option 'user' is lost.  This
means that any user can mount /cdrom, but only root can unmount it.

-- 
Måns Rullgård
mru@users.sf.net

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

Måns Rullgård wrote:
> 
> Olaf Dietsche <olaf.dietsche@t-online.de> writes:
> 
> > >>A simpler solution, that does not require changes to the kernel
> > >>would be to just move mtab to a more apropriate location. My
> > >>suggestion would be to change it from /etc/mtab to /mtab.d/mtab.
> > >>Then you could mount a tmpfs filesystem on /mtab.d. Or by making
> > >>/mtab.d a symlink, you can get the mtab file whereever you want,
> > >>including /etc.
> > >
> > > /dev/shm ? Supposed to be there on many systems anyway. Fix
> > > 'mount' and 'umount' so that if they see /etc/mtab is a symlink,
> > > they follow it and create the temp files etc in the destination
> > > directory of the link instead of in /etc. Then
> > > ln -sf /dev/shm/mtab /etc/mtab et voila
> >
> > I thought, this is what /var is for. So, /var/run, /var/lib/misc or
> > /var/etc might be more appropriate?
> 
> What if /var is mounted separately?

I agree with all of you.

/dev/shm is widely available, and is a filesystem of the desired type.
/var is intended for this kind of data, and /var/run seems intuitively
the right location. But /dev as well as /var are often mountpoints. So
to use those locations would introduce more mountpoints that will need
special care early in the startup scripts. And mounting them before
running fsck is a problem.

All of those thoughts is what lead me to the suggestion of a new
directory or symlink in the root. You can point it anywhere you want
mtab. And you don't need to mount any filesystems before the symlink
can be used. A symlink in the other direction would not work that well.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[Olaf Dietsche]

mru@users.sourceforge.net (Måns Rullgård) writes:

> Olaf Dietsche <olaf.dietsche@t-online.de> writes:
>
>> I thought, this is what /var is for. So, /var/run, /var/lib/misc or
>> /var/etc might be more appropriate?
>
> What if /var is mounted separately?

I didn't think of this, even though I have it separately on my
machine.

>> OTOH, "ln -s /proc/mounts /etc/mtab" works just fine here.
>
> The only problem I have with that is that option 'user' is lost.  This
> means that any user can mount /cdrom, but only root can unmount it.

The 'user' option is in /etc/fstab, so this is not a problem. I can
mount _and_ umount /cdrom as a simple user.

Regards, Olaf.

Re: About /etc/mtab and /proc/mounts

[Måns Rullgård]

Olaf Dietsche <olaf.dietsche@t-online.de> writes:

> >> I thought, this is what /var is for. So, /var/run, /var/lib/misc or
> >> /var/etc might be more appropriate?
> >
> > What if /var is mounted separately?
> 
> I didn't think of this, even though I have it separately on my
> machine.
> 
> >> OTOH, "ln -s /proc/mounts /etc/mtab" works just fine here.
> >
> > The only problem I have with that is that option 'user' is lost.  This
> > means that any user can mount /cdrom, but only root can unmount it.
> 
> The 'user' option is in /etc/fstab, so this is not a problem. I can
> mount _and_ umount /cdrom as a simple user.

It's strange if you can.  My mount (fairly recent) looks in fstab to
determine whether a user should be allowed to mount a device.
However, when unmounting it checks /etc/mtab to make sure it was you
who mounted it in the first place, making it impossible to unmount
someone else's cdrom.  If you use the 'users' (note the 's') option
instead any user can mount or unmount the device at any time, mtab
being ignored.

-- 
Måns Rullgård
mru@users.sf.net

Re: About /etc/mtab and /proc/mounts

[Olaf Dietsche]

mru@users.sourceforge.net (Måns Rullgård) writes:

> Olaf Dietsche <olaf.dietsche@t-online.de> writes:
>
>> The 'user' option is in /etc/fstab, so this is not a problem. I can
>> mount _and_ umount /cdrom as a simple user.
>
> It's strange if you can.  My mount (fairly recent) looks in fstab to
> determine whether a user should be allowed to mount a device.
> However, when unmounting it checks /etc/mtab to make sure it was you
> who mounted it in the first place, making it impossible to unmount
> someone else's cdrom.  If you use the 'users' (note the 's') option
> instead any user can mount or unmount the device at any time, mtab
> being ignored.

I just verified it. I and anybody else can mount and umount /cdrom. If
I mounted /cdrom, someone else can umount it.

$ mount -V
mount: mount-2.11n

$ grep user /etc/fstab
/dev/hdb/0 /cdrom iso9660 defaults,ro,unhide,user,noauto,noexec,nosuid 0 2

$ ls -l /etc/mtab 
lrwxrwxrwx    1 root     root           12 2002-09-22 02:58 /etc/mtab -> /proc/mounts

When /etc/mtab is a regular file, it works as you described.

Regards, Olaf.

Re: About /etc/mtab and /proc/mounts

[Måns Rullgård]

Olaf Dietsche <olaf.dietsche@t-online.de> writes:

> >> The 'user' option is in /etc/fstab, so this is not a problem. I can
> >> mount _and_ umount /cdrom as a simple user.
> >
> > It's strange if you can.  My mount (fairly recent) looks in fstab to
> > determine whether a user should be allowed to mount a device.
> > However, when unmounting it checks /etc/mtab to make sure it was you
> > who mounted it in the first place, making it impossible to unmount
> > someone else's cdrom.  If you use the 'users' (note the 's') option
> > instead any user can mount or unmount the device at any time, mtab
> > being ignored.
> 
> I just verified it. I and anybody else can mount and umount /cdrom. If
> I mounted /cdrom, someone else can umount it.
> 
> $ mount -V
> mount: mount-2.11n
> 
> $ grep user /etc/fstab
> /dev/hdb/0 /cdrom iso9660 defaults,ro,unhide,user,noauto,noexec,nosuid 0 2
> 
> $ ls -l /etc/mtab 
> lrwxrwxrwx    1 root     root           12 2002-09-22 02:58 /etc/mtab -> /proc/mounts
> 
> When /etc/mtab is a regular file, it works as you described.

What does your /proc/mounts look like when the cdrom is mounted?  Are
you using a standard mount, or something hacked up by RH or others?

-- 
Måns Rullgård
mru@users.sf.net

Re: About /etc/mtab and /proc/mounts

[Olaf Dietsche]

mru@users.sourceforge.net (Måns Rullgård) writes:

> What does your /proc/mounts look like when the cdrom is mounted?  Are

$ grep cdrom /proc/mounts
/dev/hdb/0 /cdrom iso9660 ro,nosuid,nodev,noexec 0 0

> you using a standard mount, or something hacked up by RH or others?

Debian unstable, but I didn't upgrade mount for quite some time.

$ dpkg -l mount
ii  mount            2.11n-4          Tools for mounting and manipulating filesystems.

Regards, Olaf.

Re: About /etc/mtab and /proc/mounts

[Miles Bader]

Kasper Dupont <kasperd@daimi.au.dk> writes:
> I don't think you can put all the information from /etc/mtab
> into /proc/mounts without breaking compatibility.

Why?  Since the option syntax is regular, presumably programs simply
ignore options they don't understand.  No?

> My suggestion would be to change it from /etc/mtab to /mtab.d/mtab.

Please, no.  don't pollute the root (_especially_ with little one-use
directories like that).

/var is clearly the right place for this; if /var isn't mounted
initially, I'd suggest that mount should simply not update any file at
that point, and the init-script that mounts /var can be responsible from
propagating information from /proc/mounts to /var/whatever.

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

Miles Bader wrote:
> 
> Kasper Dupont <kasperd@daimi.au.dk> writes:
> > I don't think you can put all the information from /etc/mtab
> > into /proc/mounts without breaking compatibility.
> 
> Why?  Since the option syntax is regular, presumably programs simply
> ignore options they don't understand.  No?

It is mostly the device field I had in mind.

> 
> > My suggestion would be to change it from /etc/mtab to /mtab.d/mtab.
> 
> Please, no.  don't pollute the root (_especially_ with little one-use
> directories like that).

Unfortunately it is the best solution I can come up with.

> 
> /var is clearly the right place for this;

Is it?

> if /var isn't mounted
> initially, I'd suggest that mount should simply not update any file at
> that point, and the init-script that mounts /var can be responsible from
> propagating information from /proc/mounts to /var/whatever.

Would you fsck /var while it is mounted?

I think part of the problem is that /var is used for both files
we want to keep across reboot, and files we do not want to keep
across reboot.

There are cases where it is undesirable to have mtab in /var,
but if mount expect to find mtab somewhere under /var, we can't
even use a symlink to get it out of there, because /var needs
to be mounted before the symlink can be followed.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[Joseph Wenninger]

Hi

Am Don, 2003-02-27 um 07.40 schrieb Kasper Dupont:
> Miles Bader wrote:
> > 
> > Kasper Dupont <kasperd@daimi.au.dk> writes:
> > > I don't think you can put all the information from /etc/mtab
> > > into /proc/mounts without breaking compatibility.
> > 

For KDE 3.1 I've written a mount watcher, which checks the modification
time of the /etc/mtab to recognize mount/unmount activity, which broke
for linux from scratch( for now, they have updated there install
instructions), because they linked to /proc/mounts, which doesn't seem
to support mtime. 
If the mtab is really completly removed, is there something else I can 
use to track mount activities from userspace ? I don't want to retrieve
the whole mounted list all the time and compare each entry to my
internally stored list, just to find out that nothing has changed
anyways.

Kind regards
Joseph Wenninger

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

Joseph Wenninger wrote:
> 
> Hi
> 
> Am Don, 2003-02-27 um 07.40 schrieb Kasper Dupont:
> > Miles Bader wrote:
> > >
> > > Kasper Dupont <kasperd@daimi.au.dk> writes:
> > > > I don't think you can put all the information from /etc/mtab
> > > > into /proc/mounts without breaking compatibility.
> > >
> 
> For KDE 3.1 I've written a mount watcher, which checks the modification
> time of the /etc/mtab to recognize mount/unmount activity, which broke
> for linux from scratch( for now, they have updated there install
> instructions), because they linked to /proc/mounts, which doesn't seem
> to support mtime.

It seems the mtime of anything under /proc simply gives the current time.
Would that be hard to change? And would anything break if /proc/mounts
gave the time of the last change? It shouldn't be a major problem to
record the time of the last sucessfull mount, remount, or unmount.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[Jamie Lokier]

Kasper Dupont wrote:
> > For KDE 3.1 I've written a mount watcher, which checks the modification
> > time of the /etc/mtab to recognize mount/unmount activity, which broke
> > for linux from scratch( for now, they have updated there install
> > instructions), because they linked to /proc/mounts, which doesn't seem
> > to support mtime.
> 
> It seems the mtime of anything under /proc simply gives the current time.
> Would that be hard to change? And would anything break if /proc/mounts
> gave the time of the last change? It shouldn't be a major problem to
> record the time of the last sucessfull mount, remount, or unmount.

It would be much better if it were possible to use
fcntl(?,F_NOTIFY,...) to monitor the contents of /proc/mounts.  (It
would have to be in a subdirectory of its own for this).

-- Jamie

Re: About /etc/mtab and /proc/mounts

[Miles Bader]

Kasper Dupont <kasperd@daimi.au.dk> writes:
> > /var is clearly the right place for this;
> 
> Is it?

Yes.  On some systems, /var and /tmp are the _only_ read-write filesystems.

> > if /var isn't mounted initially, I'd suggest that mount should
> > simply not update any file at that point, and the init-script that
> > mounts /var can be responsible from propagating information from
> > /proc/mounts to /var/whatever.
> 
> Would you fsck /var while it is mounted?

No, of course not; that's why I suggest it's up to the init scripts to
make sure that /proc/mounts gets propagated to /var/whatever.  They
usually will know enough about what's going on to take care of any
special cases and add any extra info that's relevant.

If a program such as `mount' wants to use mtab and finds that it's not
present (possibly because /var isn't mounted), it should either use
/proc/mounts instead, or just ignore it.

> I think part of the problem is that /var is used for both files
> we want to keep across reboot, and files we do not want to keep
> across reboot.

[/var/run is for `non-persistant' files]

> There are cases where it is undesirable to have mtab in /var,
> but if mount expect to find mtab somewhere under /var, we can't
> even use a symlink to get it out of there, because /var needs
> to be mounted before the symlink can be followed.

It will simply appear to mount as if the file isn't present, in which
case it should gracefully stop trying to use it [see above].

It seems like the attempt here is to somehow make everything just work
magically _without_ modifying any tools that use mtab -- and I think
that just isn't doable in every situation.

-Miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

Miles Bader wrote:
> 
> Kasper Dupont <kasperd@daimi.au.dk> writes:
> > > /var is clearly the right place for this;
> >
> > Is it?
> 
> Yes.  On some systems, /var and /tmp are the _only_ read-write filesystems.

OK, but then on such a system with my approach it would be possible to
make /mtab.d a symlink pointing to somewhere under /var.

> 
> > > if /var isn't mounted initially, I'd suggest that mount should
> > > simply not update any file at that point, and the init-script that
> > > mounts /var can be responsible from propagating information from
> > > /proc/mounts to /var/whatever.
> >
> > Would you fsck /var while it is mounted?
> 
> No, of course not; that's why I suggest it's up to the init scripts to
> make sure that /proc/mounts gets propagated to /var/whatever.  They
> usually will know enough about what's going on to take care of any
> special cases and add any extra info that's relevant.

But AFAIK fsck uses mtab.

> 
> If a program such as `mount' wants to use mtab and finds that it's not
> present (possibly because /var isn't mounted), it should either use
> /proc/mounts instead, or just ignore it.

If mtab does not exist mount will attempt to create a new one with
only the root listed.

> 
> > I think part of the problem is that /var is used for both files
> > we want to keep across reboot, and files we do not want to keep
> > across reboot.
> 
> [/var/run is for `non-persistant' files]

But that doesn't solve the problem with ordering. If we don't want
to change a lot of userspace utilities and the order in which things
are done during boot, we need /var/run mounted earlier than /var.
And /var/run is not the only directory with files we do not want to
keep across boot. There are some in /var/lock too, and AFAIR a few
other locations.

> 
> > There are cases where it is undesirable to have mtab in /var,
> > but if mount expect to find mtab somewhere under /var, we can't
> > even use a symlink to get it out of there, because /var needs
> > to be mounted before the symlink can be followed.
> 
> It will simply appear to mount as if the file isn't present, in which
> case it should gracefully stop trying to use it [see above].
> 
> It seems like the attempt here is to somehow make everything just work
> magically _without_ modifying any tools that use mtab -- and I think
> that just isn't doable in every situation.

Maybe not, but I certainly don't want to change every program that
reads mtab. If we can limit the changes to those tools that needs
to write mtab, it might be feasible.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[Miles Bader]

Kasper Dupont <kasperd@daimi.au.dk> writes:
> > Yes.  On some systems, /var and /tmp are the _only_ read-write filesystems.
> 
> OK, but then on such a system with my approach it would be possible to
> make /mtab.d a symlink pointing to somewhere under /var.

... you could do the same with /etc/mtab.

In fact since /etc is almost guaranteed to be on the same filesystem as
/, it seems like "/mtab.d" offers zero advantages over just /etc/mtab --
the case where /etc/mtab is the most annoying is when /etc is R/O, but
this almost always means that / will be R/O, making /mtab.d useless too.

> But AFAIK fsck uses mtab.

It uses /etc/fstab.

> If mtab does not exist mount will attempt to create a new one with
> only the root listed.

Unless you use the `-n' flag, which an init-script should do if it
knows there's something wierd required to get /var mounted or something.

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: About /etc/mtab and /proc/mounts

[jw schultz]

On Thu, Feb 27, 2003 at 05:42:30PM +0900, Miles Bader wrote:
> Kasper Dupont <kasperd@daimi.au.dk> writes:
> > > Yes.  On some systems, /var and /tmp are the _only_ read-write filesystems.
> > 
> > OK, but then on such a system with my approach it would be possible to
> > make /mtab.d a symlink pointing to somewhere under /var.
> 
> ... you could do the same with /etc/mtab.
> 
> In fact since /etc is almost guaranteed to be on the same filesystem as
> /, it seems like "/mtab.d" offers zero advantages over just /etc/mtab --
> the case where /etc/mtab is the most annoying is when /etc is R/O, but
> this almost always means that / will be R/O, making /mtab.d useless too.

If you netboot /etc as its own filesystem make sense.  Why
duplicate the rest of root just for /etc.  /etc, /var and
/tmp are the only filesystems that have much reason to be
unique to a system; all others are easily sharable and most
others read-only.

> 
> > But AFAIK fsck uses mtab.
> 
> It uses /etc/fstab.
> 
> > If mtab does not exist mount will attempt to create a new one with
> > only the root listed.
> 
> Unless you use the `-n' flag, which an init-script should do if it
> knows there's something wierd required to get /var mounted or something.

<voice of annoyance>
/etc/mtab is a hack.  I suspect it was done so that fsck, df
and umount wouldn't have to read /dev/kmem.  We now have
much better ways to get data out of the kernel.

The idea of storing the list of mounted filesystems on a
mounted filesystem is a bad idea from the get-go.  The only
advantage it ever really had was the possibility to manually
play mountpoint monte with mv.  Duplicating the in-kernel
data externally begs for inconsistencies that only get worse
with pivot root.

Let the data reside in the kernel and have a procfs or sysfs
entity for it.  A symlink from /etc/mtab can keep the old
tools happy.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: About /etc/mtab and /proc/mounts

[Miles Bader]

jw schultz <jw@pegasys.ws> writes:
> /etc/mtab is a hack.  I suspect it was done so that fsck, df
> and umount wouldn't have to read /dev/kmem.  We now have
> much better ways to get data out of the kernel.

Oh, I very much agree.  I'm just trying to say that it's not really any
worse than the _other_ stupid hacks being suggested...

I think making /proc/{mount,mtab,...,whatever} work correctly is
certainly the best thing to do.

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

Miles Bader wrote:
> 
> I think making /proc/{mount,mtab,...,whatever} work correctly is
> certainly the best thing to do.

I think we all agree on that. But then what is the correct way for
that to work? And is that possible? Should any of the fields be
written by userspace utilities, or is the kernel supposed to know
the right value for every field? What should be in the device
field in case of loopback and bind mounts?

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[Denis Vlasenko]

On 27 February 2003 11:21, jw schultz wrote:
> On Thu, Feb 27, 2003 at 05:42:30PM +0900, Miles Bader wrote:
> > Kasper Dupont <kasperd@daimi.au.dk> writes:
> > > > Yes.  On some systems, /var and /tmp are the _only_ read-write
> > > > filesystems.
> > >
> > > OK, but then on such a system with my approach it would be
> > > possible to make /mtab.d a symlink pointing to somewhere under
> > > /var.
> >
> > ... you could do the same with /etc/mtab.
> >
> > In fact since /etc is almost guaranteed to be on the same
> > filesystem as /, it seems like "/mtab.d" offers zero advantages
> > over just /etc/mtab -- the case where /etc/mtab is the most
> > annoying is when /etc is R/O, but this almost always means that /
> > will be R/O, making /mtab.d useless too.
>
> If you netboot /etc as its own filesystem make sense.  Why
> duplicate the rest of root just for /etc.  /etc, /var and
> /tmp are the only filesystems that have much reason to be
> unique to a system; all others are easily sharable and most
> others read-only.

This is my netboot root fs, it is shared across all workstations
(NB: .local is "mount --bind"ed to workstation-private directory):

# ls -la /
drwxr-xr-x   6 root     root         4096 Mar 12  2002 .local
drwxr-xr-x  15 root     root         4096 Feb 14 11:12 .share
dr-xr-xr-x   2 root     root         4096 Jan 16 14:29 bin
dr-xr-xr-x  20 root     root         1024 Feb  4 13:23 boot
drwxr-xr-x   1 root     root            0 Jan  1  1970 dev
drwxr-xr-x   3 root     root         4096 Jan 16 14:29 lib
dr-xr-xr-x  68 root     root            0 Feb 27 15:42 proc
lrwxrwxrwx   1 root     root            3 Oct 24 15:20 sbin -> bin
lrwxrwxrwx   1 root     root           12 Nov 12  2001 root -> /.share/root
lrwxrwxrwx   1 root     root           12 Nov 12  2001 home -> /.share/home
lrwxrwxrwx   1 root     root           11 Nov 12  2001 usr -> /.share/usr
lrwxrwxrwx   1 root     root           11 Nov 12  2001 mnt -> /.local/mnt
lrwxrwxrwx   1 root     root           11 Jun  7  2002 etc -> /.local/etc
lrwxrwxrwx   1 root     root           11 Nov 12  2001 tmp -> /.local/tmp
lrwxrwxrwx   1 root     root           11 Nov 12  2001 var -> /.local/var
--
vda

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

Denis Vlasenko wrote:
> 
> lrwxrwxrwx   1 root     root           12 Nov 12  2001 root -> /.share/root

Wouldn't it be best to keep /root on the root filesystem?
It is rarely large, and if you need to log in as root to
fix some mounting problem, I guess you want your home
directory.

> lrwxrwxrwx   1 root     root           11 Nov 12  2001 mnt -> /.local/mnt

What is the point in making mnt a local directory? All
it contains are some directories to serve as mountpoints.
I guess you are going to mount something on top of every
subdirectory in mnt anyway.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[Denis Vlasenko]

On 28 February 2003 01:28, Kasper Dupont wrote:
> Denis Vlasenko wrote:
> > lrwxrwxrwx   1 root     root           12 Nov 12  2001 root ->
> > /.share/root
>
> Wouldn't it be best to keep /root on the root filesystem?
> It is rarely large, and if you need to log in as root to
> fix some mounting problem, I guess you want your home
> directory.

No. My rootfs is RO. My home dir shouldn't be.

> > lrwxrwxrwx   1 root     root           11 Nov 12  2001 mnt ->
> > /.local/mnt
>
> What is the point in making mnt a local directory? All
> it contains are some directories to serve as mountpoints.
> I guess you are going to mount something on top of every
> subdirectory in mnt anyway.

Yes.
--
vda

Re: About /etc/mtab and /proc/mounts

[DervishD]

    Hi J.W. :)

 jw schultz dixit:
> The idea of storing the list of mounted filesystems on a
> mounted filesystem is a bad idea from the get-go.

    I'm with you on this, with an exception. It's a bad idea provided
you have some way to know what filesystems are mounted, together with
the options, etc... /bin/mount knows all those options, obviously,
and the kernel not always (AFAIK). Don't know why.

> Let the data reside in the kernel and have a procfs or sysfs
> entity for it.  A symlink from /etc/mtab can keep the old
> tools happy.

    That's what I propose, too. Even if this lead to technical
difficulties, /etc/mtab is, IMHO, obsolete and a better solution
tried instead. Obviously I don't have such a solution, but I think
that a procfs based solution and a symlink for mtab will work quite
good. I know: some systems don't have procfs, but I think that those
systems will have a read-only /etc anyway... Other solution is to
link /etc/mtab to a point at /var. If 'mount' treats specially the
mtab if it is a symlink... well, IMHO this is not correct. Yes, this
can lead to an attack, but: 'mount' is a setuid program, and only
root can symlink /etc/mtab, true?

    Raúl

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

DervishD wrote:
> 
> If 'mount' treats specially the
> mtab if it is a symlink... well, IMHO this is not correct. Yes, this
> can lead to an attack, but: 'mount' is a setuid program, and only
> root can symlink /etc/mtab, true?

The reason for mount not to update /etc/mtab if it is a symlink is
not security concerns, but rather that it could be a symlink to
/proc/mounts. Another problem is the way the update is actually
done. A lockfile named /etc/mtab~ is created, and a new mtab is
written to /etc/mtab.tmp which is later renamed on top of mtab.

Some of this can obviously be solved by changing mount. But if we
are going to change mount in non-trivial ways, we should aim for a
better longterm solution. It would be possible for mount to start
from /et/mtab and use readlink until the actual location is found.
Then if the path starts with /proc/ the update can be skipped, or
done in a different way. And if the location is outside /proc then
create lockfilename and tempfilename by appending to this path.

But all that is IMHO a bad solution. Getting the actual location
right is nontrivial. And we should rather aim for an implementation
in /proc and have mount write there directly. But there are a few
open questions I'd like answered before trying to implement a
/proc/mtab.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[jw schultz]

On Sun, Mar 02, 2003 at 03:16:21PM +0100, Kasper Dupont wrote:
> DervishD wrote:
> > 
> > If 'mount' treats specially the
> > mtab if it is a symlink... well, IMHO this is not correct. Yes, this
> > can lead to an attack, but: 'mount' is a setuid program, and only
> > root can symlink /etc/mtab, true?
> 
> The reason for mount not to update /etc/mtab if it is a symlink is
> not security concerns, but rather that it could be a symlink to
> /proc/mounts. Another problem is the way the update is actually
> done. A lockfile named /etc/mtab~ is created, and a new mtab is
> written to /etc/mtab.tmp which is later renamed on top of mtab.
> 
> Some of this can obviously be solved by changing mount. But if we
> are going to change mount in non-trivial ways, we should aim for a
> better longterm solution. It would be possible for mount to start
> from /et/mtab and use readlink until the actual location is found.
> Then if the path starts with /proc/ the update can be skipped, or
> done in a different way. And if the location is outside /proc then
> create lockfilename and tempfilename by appending to this path.
> 
> But all that is IMHO a bad solution. Getting the actual location
> right is nontrivial. And we should rather aim for an implementation
> in /proc and have mount write there directly. But there are a few
> open questions I'd like answered before trying to implement a
> /proc/mtab.

You are talking about adding hacks to workaround the
original hack.  Nothing should write to mtab.  Say it with
me "Nothing should write to mtab".

mount(8) and umount(8) are the only almost the only things that
write mtab all others are readers.  I may be wrong but the
data argument to mount(2) looks like it should support
everything missing from /proc/mounts.  Alternatively change
mount(2) and mount(8) and any other mount(2) callers will
be revealed.

The reason to leave a /etc/mtab symlink is so that the
old tools other than (u)mount don't need updates.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

jw schultz wrote:
> 
> On Sun, Mar 02, 2003 at 03:16:21PM +0100, Kasper Dupont wrote:
> > And we should rather aim for an implementation
> > in /proc and have mount write there directly. But there are a few
> > open questions I'd like answered before trying to implement a
> > /proc/mtab.
> 
> You are talking about adding hacks to workaround the
> original hack.  Nothing should write to mtab.  Say it with
> me "Nothing should write to mtab".

You obviously haven't read all I have written. There is nothing
I'd like more than an implementation where the kernel could
always provide the correct information, and mount would never
have to store it anywhere else. However I don't know if that is
possible, and until somebody proves it possible, we will need
mtab.

There are three groups of options:
- VFS options
- Filesystem options
- Userspace options

The VFS options are given to the mount system call in a bitmask,
and they are available through the /proc/mounts pseudo file.

The filesystem options are more complicated. They are given to
mount in the data argument. When the filesystem is first mounted
it would be trivial to save the string and provide it in
/proc/mounts (or /proc/mtab). But if the filesystem is later
remounted with a different set of options, it is nontrivial to
know in general which parts should be taken from the old string,
and which parts should be taken from the new strings. Even some
of the filesystems have gotten this wrong and would read
uninitialized variables if a remount did not specify every single
possible option.

Finally the userspace options are used by mount itself. One example
is in the case of a user option being specified in /etc/fstab,
mount will store the name of the user calling mount in /etc/mtab.
I don't know if that kind of options are also given in the data
argument, but they have no business in the kernel, they are only
used by a feature implemented in userspace. But since they are
related to a mount point, it would be nice to have the kernel
delete them once the mountpoint is unmounted.

As long as these options is not yet stored in the kernel, we
need /etc/mtab. The question is how to get them into the kernel.
One possibility would be that mount could open /proc/mtab for
writing and write a single line in the usual format. Otherwise
we could extent mount with another string argument, or we could
put them into the data argument, where they really don't belong.

Since you seem to have some opinions on how this should be done,
I'd like to know how *you* would store those options.

Another problem is the device field, in the most common cases
/etc/mtab and /proc/mounts will contain the same. But in the
case of loopback mounts and bind mounts they are different.

I think the current value of the device field in /etc/mtab is
somewhat broken for bind mounts, because the source could be
unmounted before the target. The loopback case is not optimal
either, because it works differently if you manually use
losetup and if you let mount do it by specifying -o loop.
Sometimes it is desirable to let mount automatically detach
the loopback device even if it was not setup using -o loop,
but that is not always the case.

Before we can get rid of /etc/mtab we need to agree on how
to solve those problems. There might be other cases I don't
know about, where /etc/mtab contains special values.

The remaining fields is AFAIK no problem, the current
/proc/mounts implementation get them right. The target
field in /proc/mounts did get fixed with 2.4, and the
filesystem field also contains the right value. In the case
of bind mounts /etc/mtab will contain none in the filesystem
field, but I consider that to be a bug and /proc/mounts to
be correct. And finally the last two fields always contain
0, and only exist to keep the format identical with /etc/fstab.

> 
> mount(8) and umount(8) are the only almost the only things that
> write mtab all others are readers.

What are you saying? Are they the only writers, or are there
other writers? IIRC smbmount will write /etc/mtab on its own.

> I may be wrong but the
> data argument to mount(2) looks like it should support
> everything missing from /proc/mounts.

I don't think it has everything.

> Alternatively change
> mount(2) and mount(8) and any other mount(2) callers will
> be revealed.

Sounds like a good idea on a long term. Probably it should
be possible to get warnings from the kernel like it has been
done with other obsolete interfaces.

> 
> The reason to leave a /etc/mtab symlink is so that the
> old tools other than (u)mount don't need updates.

On a long term I agree with that. But first we need a
replacement for /etc/mtab. I have come with some suggestions,
but there are still a few blanks to fill in.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[jw schultz]

On Mon, Mar 03, 2003 at 01:22:46PM +0100, Kasper Dupont wrote:
> jw schultz wrote:
> > 
> > On Sun, Mar 02, 2003 at 03:16:21PM +0100, Kasper Dupont wrote:
> > > And we should rather aim for an implementation
> > > in /proc and have mount write there directly. But there are a few
> > > open questions I'd like answered before trying to implement a
> > > /proc/mtab.
> > 
> > You are talking about adding hacks to workaround the
> > original hack.  Nothing should write to mtab.  Say it with
> > me "Nothing should write to mtab".
> 
> You obviously haven't read all I have written. There is nothing
> I'd like more than an implementation where the kernel could
> always provide the correct information, and mount would never
> have to store it anywhere else. However I don't know if that is
> possible, and until somebody proves it possible, we will need
> mtab.

I had read all you wrote in this thread.  I'll grant that i
might have missed what you wrote elsewhere or perhaps what you
implied.

> There are three groups of options:
> - VFS options
> - Filesystem options
> - Userspace options
> 
> The VFS options are given to the mount system call in a bitmask,
> and they are available through the /proc/mounts pseudo file.
> 
> The filesystem options are more complicated. They are given to
> mount in the data argument. When the filesystem is first mounted
> it would be trivial to save the string and provide it in
> /proc/mounts (or /proc/mtab). But if the filesystem is later
> remounted with a different set of options, it is nontrivial to
> know in general which parts should be taken from the old string,
> and which parts should be taken from the new strings. Even some
> of the filesystems have gotten this wrong and would read
> uninitialized variables if a remount did not specify every single
> possible option.
> 
> Finally the userspace options are used by mount itself. One example
> is in the case of a user option being specified in /etc/fstab,
> mount will store the name of the user calling mount in /etc/mtab.
> I don't know if that kind of options are also given in the data
> argument, but they have no business in the kernel, they are only
> used by a feature implemented in userspace. But since they are
> related to a mount point, it would be nice to have the kernel
> delete them once the mountpoint is unmounted.

OK.  I was less that certain that there weren't options that
couldn't be listed in data or flags.  It makes sense that
there would be.

> As long as these options is not yet stored in the kernel, we
> need /etc/mtab. The question is how to get them into the kernel.
> One possibility would be that mount could open /proc/mtab for
> writing and write a single line in the usual format. Otherwise
> we could extent mount with another string argument, or we could
> put them into the data argument, where they really don't belong.
> 
> Since you seem to have some opinions on how this should be done,
> I'd like to know how *you* would store those options.

Writing to /proc/mtab like we do /etc/mtab means allowing
full file read,write,truncate,seek functionality on a
multi-page tlob just to emulate current behavior and support
a second data source with a disconnect from the kernel.

[description of problems with /etc/mtab, kernel disconnect]

> Before we can get rid of /etc/mtab we need to agree on how
> to solve those problems. There might be other cases I don't
> know about, where /etc/mtab contains special values.
> 
> The remaining fields is AFAIK no problem, the current
> /proc/mounts implementation get them right. The target
> field in /proc/mounts did get fixed with 2.4, and the
> filesystem field also contains the right value. In the case
> of bind mounts /etc/mtab will contain none in the filesystem
> field, but I consider that to be a bug and /proc/mounts to
> be correct. And finally the last two fields always contain
> 0, and only exist to keep the format identical with /etc/fstab.
> 
> > 
> > mount(8) and umount(8) are the only almost the only things that
> > write mtab all others are readers.
> 
> What are you saying? Are they the only writers, or are there
> other writers? IIRC smbmount will write /etc/mtab on its own.

Hence the qualifier.  My point is that the list of things
that call mount(2) directly and write to /etc/mtab is small
and the most critical of them are linux specific.  This
gives us a degree of freedom in our approach.

> > I may be wrong but the
> > data argument to mount(2) looks like it should support
> > everything missing from /proc/mounts.
> 
> I don't think it has everything.

OK.  So it doesn't

> > Alternatively change
> > mount(2) and mount(8) and any other mount(2) callers will
> > be revealed.
> 
> Sounds like a good idea on a long term. Probably it should
> be possible to get warnings from the kernel like it has been
> done with other obsolete interfaces.
> 
> > 
> > The reason to leave a /etc/mtab symlink is so that the
> > old tools other than (u)mount don't need updates.
> 
> On a long term I agree with that. But first we need a
> replacement for /etc/mtab. I have come with some suggestions,
> but there are still a few blanks to fill in.

What i would lean towards, assuming that data couldn't list
all options not supported by mountflags would be to add a
char *userdata or useropts argument.  That would be attached
to struct vfsmount.  Userdata would be what /proc/mtab or
whatever reported, either as the option list or the whole
line.

To detect the old interface users a NULL userdata or (as
alternatives) a missing MS_USERDATA flag or calling the old
mount syscall would cause a warning that identifies the
offending process.  For the short term either construct a
fake userdata or mtab could fallback to what /proc/mounts
does when it hits NULL.  Long term might be to fail mount(2)
on such an error.

I think our goals are the same.  The only reason i chimed in
on this discussion was to remind people that /etc/mtab was a
hack we no longer really need and then because it sounded
like what was being proposed was to emulate that
obsolescence with another layer of cruft.  Emulating the
read behavior is good.  A link in /etc is needed to
accommodate the numerous utilities that read /etc/mtab.  It
is emulating the write behavior, or persisting in preserving
the disconnected file, that makes me a bit uncomfortable.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

jw schultz wrote:
> 
> I had read all you wrote in this thread.  I'll grant that i
> might have missed what you wrote elsewhere or perhaps what you
> implied.

Hmm, maybe it was somewhere else I wrote it then.

> 
> Writing to /proc/mtab like we do /etc/mtab means allowing
> full file read,write,truncate,seek functionality on a
> multi-page tlob just to emulate current behavior and support
> a second data source with a disconnect from the kernel.

I certainly don't want that. I'd much rather see something
slightly similar to files in /proc/sys/. I only want the
write system call to work, and I don't want the write call
to make use of any file offset. (Maybe it would require a
buffer for cases where a write does not end with a newline,
but that is just a minor detail.) Every full line written
to /proc/mtab would then be parsed (as simple as finding
the spaces and verify that there are exactly five). The
relevant fields in the mountpoint listed in field two will
then be updated.

> > >
> > > mount(8) and umount(8) are the only almost the only things that
> > > write mtab all others are readers.
> >
> > What are you saying? Are they the only writers, or are there
> > other writers? IIRC smbmount will write /etc/mtab on its own.
> 
> Hence the qualifier.  My point is that the list of things
> that call mount(2) directly and write to /etc/mtab is small
> and the most critical of them are linux specific.  This
> gives us a degree of freedom in our approach.

We agree on that.

> 
> What i would lean towards, assuming that data couldn't list
> all options not supported by mountflags would be to add a
> char *userdata or useropts argument.  That would be attached
> to struct vfsmount.  Userdata would be what /proc/mtab or
> whatever reported, either as the option list or the whole
> line.
> 
> To detect the old interface users a NULL userdata or (as
> alternatives) a missing MS_USERDATA flag or calling the old
> mount syscall would cause a warning that identifies the
> offending process.  For the short term either construct a
> fake userdata or mtab could fallback to what /proc/mounts
> does when it hits NULL.  Long term might be to fail mount(2)
> on such an error.

That is another possible solution. And as I think a litle
more about it, that is probably a better than the solution I
suggested.

There are a few details of the API that needs to be defined
before it can be implemented. So I hope people will say how
they like it. As I see it there are a few different
possibilities:

1) Make a new mount system call. Finally get rid of the old
   magic value in the flag register and add the extra argument
   which is then required. Make the old mount system call
   obsolete, but keep it for some versions. The old mount
   system call should then just behave as if the user data
   was the empty string.

2) Add a new flag for the old mount system call, which
   indicates that there is one more argument containing the
   user data.

> 
> I think our goals are the same.

Yes.

> The only reason i chimed in
> on this discussion was to remind people that /etc/mtab was a
> hack we no longer really need and then because it sounded
> like what was being proposed was to emulate that
> obsolescence with another layer of cruft.

I never wanted a /proc/mtab to emulate the existing /etc/mtab.
In fact I wanted it to resemble the existing /proc/mounts as
much as possible, just with a few new features and probably
a different string in the device field in some cases.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[jw schultz]

On Wed, Mar 05, 2003 at 01:57:57PM +0100, Kasper Dupont wrote:
> jw schultz wrote:
> > Writing to /proc/mtab like we do /etc/mtab means allowing
> > full file read,write,truncate,seek functionality on a
> > multi-page tlob just to emulate current behavior and support
> > a second data source with a disconnect from the kernel.
> 
> I certainly don't want that. I'd much rather see something
> slightly similar to files in /proc/sys/. I only want the
> write system call to work, and I don't want the write call
> to make use of any file offset. (Maybe it would require a
> buffer for cases where a write does not end with a newline,
> but that is just a minor detail.) Every full line written
> to /proc/mtab would then be parsed (as simple as finding
> the spaces and verify that there are exactly five). The
> relevant fields in the mountpoint listed in field two will
> then be updated.

And umount?  Anything that umounts or remountes a filesystem
has to modify /etc/mtab to remove or alter the relevant
line.

I traced a umount and it did the write-to-temp+rename 
routine.  I wouldn't expect that to work to well in proc.
And you should have seen the ugly fstat64,_llseek,write
loop it used.

To put this in kernel means changing how it is updated.
Once we do that we might as well go all the way.

> > What i would lean towards, assuming that data couldn't list
> > all options not supported by mountflags would be to add a
> > char *userdata or useropts argument.  That would be attached
> > to struct vfsmount.  Userdata would be what /proc/mtab or
> > whatever reported, either as the option list or the whole
> > line.
> > 
> > To detect the old interface users a NULL userdata or (as
> > alternatives) a missing MS_USERDATA flag or calling the old
> > mount syscall would cause a warning that identifies the
> > offending process.  For the short term either construct a
> > fake userdata or mtab could fallback to what /proc/mounts
> > does when it hits NULL.  Long term might be to fail mount(2)
> > on such an error.
> 
> That is another possible solution. And as I think a litle
> more about it, that is probably a better than the solution I
> suggested.
> 
> There are a few details of the API that needs to be defined
> before it can be implemented. So I hope people will say how
> they like it. As I see it there are a few different
> possibilities:
> 
> 1) Make a new mount system call. Finally get rid of the old
>    magic value in the flag register and add the extra argument
>    which is then required. Make the old mount system call
>    obsolete, but keep it for some versions. The old mount
>    system call should then just behave as if the user data
>    was the empty string.
> 
> 2) Add a new flag for the old mount system call, which
>    indicates that there is one more argument containing the
>    user data.

#2 with warnings i like better than keeping a deprecated mount
syscall until 2038.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

jw schultz wrote:
> 
> And umount?  Anything that umounts or remountes a filesystem
> has to modify /etc/mtab to remove or alter the relevant
> line.

That is not an issue. With my suggestion the line is automatically
removed by the kernel at umount. If the umount program changes the
line before calling the umount system call, the changed line is
discareded anyway. If the umount program try to change the line
after calling umount, it is simply ignored. Currently this is not
going to happen anyway with a umount program that see /etc/mtab
is a symlink and simply skips the update. An updated umount
program for the new approach will simply remove all the code
related to updating mtab.

> 
> To put this in kernel means changing how it is updated.
> Once we do that we might as well go all the way.

Yes, in this case it means umount is not going to write at all.
It only needs to read the file for the user specific options.
(To know if the calling user is allowed to umount.) The read can
be done either through the /etc/mtab symlink or the /proc
interface, I prefer the later.

> >
> > 1) Make a new mount system call. Finally get rid of the old
> >    magic value in the flag register and add the extra argument
> >    which is then required. Make the old mount system call
> >    obsolete, but keep it for some versions. The old mount
> >    system call should then just behave as if the user data
> >    was the empty string.
> >
> > 2) Add a new flag for the old mount system call, which
> >    indicates that there is one more argument containing the
> >    user data.
> 
> #2 with warnings i like better than keeping a deprecated mount
> syscall until 2038.

But by adding options to the existing systemcall we are going
to keep historic options and magic values in that system call
forever. With the new system call we have at least collected all
the historic parts in a single obsolete system call, that can
eventually be removed. Anyway I think this is a minor detail,
both approaches will be an improvement over the current mtab
file. So whatever people prefer I'd be happy with.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[DervishD]

    Hi Kasper and J.W. :)

 Kasper Dupont dixit:
> As long as these options is not yet stored in the kernel, we
> need /etc/mtab. The question is how to get them into the kernel.

    That was my first question. Certainly there should be a way to
tell the kernel those options, but... Do we really need them. As you
said, those options (the user options) are used by mount itself, so
the kernel doesn't need to know them. If we are concerned by the
'user' option, that allows normal users to mount and umount
filesystems, and that option is not in the syscall, I think that it
should be done with other approach. See below.

> Before we can get rid of /etc/mtab we need to agree on how
> to solve those problems. There might be other cases I don't
> know about, where /etc/mtab contains special values.

    In the case of normal users mounting and umounting filesystems,
this could be done throught the use of capabilities, I think. And
surely better methods exist. If we could tell the kernel that some
user 'a' mounted filesystem 'f', then at umount time the umount
syscall will only success if root or 'a' umounts 'f'. The question is
if we can tell it to the kernel. The mount syscall maybe? Maybe a VFS
flag just for this purpose (that seems to be very important). Other
user flats like the permissions, etc... are merely informative and
that info is present in /etc/fstab anyway (usually).

    The loopback issue is more a problem of consistency, I think.

    Raúl

Re: About /etc/mtab and /proc/mounts

[DervishD]

    Hi Kasper :)

 Kasper Dupont dixit:
> > If 'mount' treats specially the
> > mtab if it is a symlink... well, IMHO this is not correct. Yes, this
> The reason for mount not to update /etc/mtab if it is a symlink is
> not security concerns, but rather that it could be a symlink to
> /proc/mounts. Another problem is the way the update is actually
> done. A lockfile named /etc/mtab~ is created, and a new mtab is
> written to /etc/mtab.tmp which is later renamed on top of mtab.

    The lockfile was the first reason why we did the symlink. The
/etc was readonly and mount failed.
 
> But if we
> are going to change mount in non-trivial ways, we should aim for a
> better longterm solution.

    You're completely right ;) But, just as I told before, I have no
good solution. I don't remember clearly, but I think that we use
finally another solution for the embedded system, by using a 'fake'
etc, writeable, and after booting, mounting a readonly etc over the
old one, or something like that. Pretty good (I suppose) for the
embedded system, but not a solution for everyday use, IMHO.

    By now I will do with /etc/mtab, but I think I will replace it
with a symlink to /proc, no matter if I lose options, etc... And
really I would like to write my own mount, just for my system, as
I've already done with other binaries. That's what I like free
software: I can write my own software without doing all the work from
zero, using the brains of people far more clever than me for helping
in the effort ;))

    BTW, thanks for your interest in the issue :))

    Raúl

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

Miles Bader wrote:
> 
> Kasper Dupont <kasperd@daimi.au.dk> writes:
> > > Yes.  On some systems, /var and /tmp are the _only_ read-write filesystems.
> >
> > OK, but then on such a system with my approach it would be possible to
> > make /mtab.d a symlink pointing to somewhere under /var.
> 
> ... you could do the same with /etc/mtab.

No.

1) mtab being a symlink is interpreted differently by mount. You
   need to symlink the directory containing mtab, not mtab itself.
2) Some people might want /etc to be mounted from a different
   filesystem.

My first change was to use /etc/mtab.d/mtab, and that works fine
as long as /etc is on the root filesystem.

> 
> In fact since /etc is almost guaranteed to be on the same filesystem as
> /, it seems like "/mtab.d" offers zero advantages over just /etc/mtab --
> the case where /etc/mtab is the most annoying is when /etc is R/O, but
> this almost always means that / will be R/O, making /mtab.d useless too.

If /etc is in fact on the root, then /etc/mtab.d/mtab will work
as well as /mtab.d/mtab. But /etc/mtab does have a disadvantage
because I cannot symlink it to a different location. All I want
is the possibility to place a symlink pointing to the most
desired location for the particular system. So the symlink itself
must be guaranteed to be on the root. Is there any directory
beyond / which we can be sure is on the root filesystem?
Introducing problems just because you don't want to look at the
entry in the root seems like a bad idea to me. I think we need a
location that is guaranteed to be on the root filesystem, which
could be the root itself, if it needs to.

But perhaps we should then say that we require /etc to be on the
root filesystem. Since people are going to need a lot of hacks
anyway if they want their /etc elsewhere. In that case I just
propose we move mtab into a subdirectory, because then that
subdirectory can be replaced by a symlink if anybody desires to.
And the symlink itself can be considered a configuration option
specifying the location of mtab, and as such does belong in /etc.

> 
> > But AFAIK fsck uses mtab.
> 
> It uses /etc/fstab.

[kasperd:pts/0:~] grep /etc/mtab /sbin/fsck*
Binary file /sbin/fsck.ext2 matches
Binary file /sbin/fsck.ext3 matches
Binary file /sbin/fsck.minix matches
[kasperd:pts/0:~] 

> 
> > If mtab does not exist mount will attempt to create a new one with
> > only the root listed.
> 
> Unless you use the `-n' flag, which an init-script should do if it
> knows there's something wierd required to get /var mounted or something.

Of course the -n flag can be used to some extent, but that
doesn't solve all our problems. Current rc.sysinit
implementations does use -n to mount a few filesystems, and
later uses -f to initialize the mtab. But all that happens
before running fsck, so if /var is mounted that early, we
are going to fsck it mounted.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[Miles Bader]

Kasper Dupont <kasperd@daimi.au.dk> writes:
> > > But AFAIK fsck uses mtab.
> > 
> > It uses /etc/fstab.
> 
> [kasperd:pts/0:~] grep /etc/mtab /sbin/fsck*
> Binary file /sbin/fsck.ext2 matches
> Binary file /sbin/fsck.ext3 matches
> Binary file /sbin/fsck.minix matches
> [kasperd:pts/0:~] 

God know why; the versions (e2fsprogs 1.32) on my system don't, so it's
probably not something very important.  fsck should still work fine.

> > Unless you use the `-n' flag, which an init-script should do if it
> > knows there's something wierd required to get /var mounted or something.
> 
> Of course the -n flag can be used to some extent, but that doesn't
> solve all our problems.  Current rc.sysinit implementations does use
> -n to mount a few filesystems, and later uses -f to initialize the
> mtab.  But all that happens before running fsck, so if /var is mounted
> that early, we are going to fsck it mounted.

So the init scripts are badly written, what can I say?  `Don't do that.'

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: About /etc/mtab and /proc/mounts

[Gabriel Paubert]

On Thu, Feb 27, 2003 at 06:58:59PM +0900, Miles Bader wrote:
> Kasper Dupont <kasperd@daimi.au.dk> writes:
> > > > But AFAIK fsck uses mtab.
> > > 
> > > It uses /etc/fstab.
> > 
> > [kasperd:pts/0:~] grep /etc/mtab /sbin/fsck*
> > Binary file /sbin/fsck.ext2 matches
> > Binary file /sbin/fsck.ext3 matches
> > Binary file /sbin/fsck.minix matches
> > [kasperd:pts/0:~] 
> 
> God know why; the versions (e2fsprogs 1.32) on my system don't, so it's
> probably not something very important.  fsck should still work fine.

Do you have a statically or dynamically linked e2fsck? On my system
/etc/mtab is not in /sbin/e2fsck but it is in /lib/libext2fs.so.2 and
also in the statically linked version of e2fsck.

	Gabriel

Re: About /etc/mtab and /proc/mounts

[Joseph Wenninger]

Hi

Am Don, 2003-02-27 um 07.40 schrieb Kasper Dupont:
> Miles Bader wrote:
> > 
> > Kasper Dupont <kasperd@daimi.au.dk> writes:
> > > I don't think you can put all the information from /etc/mtab
> > > into /proc/mounts without breaking compatibility.
> > 

For KDE 3.1 I've written a mount watcher, which checks the modification
time of the /etc/mtab to recognize mount/unmount activity, which broke
for linux from scratch( for now, they have updated there install
instructions), because they linked to /proc/mounts, which doesn't seem
to support mtime. 
If the mtab is really completly removed, is there something else I can 
use to track mount activities from userspace ? I don't want to retrieve
the whole mounted list all the time and compare each entry to my
internally stored list, just to find out that nothing has changed
anyways.

Kind regards
Joseph Wenninger

Re: About /etc/mtab and /proc/mounts

[Dominik Kubla]

On Thursday 27 February 2003 07:40, Kasper Dupont wrote:
> Miles Bader wrote:
> > Kasper Dupont <kasperd@daimi.au.dk> writes:

> > > My suggestion would be to change it from /etc/mtab to /mtab.d/mtab.
> >
> > Please, no.  don't pollute the root (_especially_ with little one-use
> > directories like that).
>
> Unfortunately it is the best solution I can come up with.
>
> > /var is clearly the right place for this;
>
> Is it?

I would recommend to replace /etc/mtab with a pseudo-FS like Sun did
for /etc/mnttab:

# uname -rs
SunOS 5.8
# mount -p
...
mnttab - /etc/mnttab mntfs - no dev=39c0000
...

Regards,
   Dominik
-- 
"What this  country needs is  a short, victorious war  to stem the  tide of
revolution." (V.K. von Plehve, Russian Minister  of Interior on the  eve of
the Russo-Japanese war.)

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

Dominik Kubla wrote:
> 
> I would recommend to replace /etc/mtab with a pseudo-FS like Sun did
> for /etc/mnttab:
> 
> # uname -rs
> SunOS 5.8
> # mount -p
> ...
> mnttab - /etc/mnttab mntfs - no dev=39c0000
> ...

How does that thing behave? I have considered a /proc/mtab implementation,
that might be slightly similar. It would have to be like /proc/mounts, but
differ in a few fields. The mountpoint and filesystem fields should be
exactly like /proc/mounts, while the device and options fields should be
strings initialized with the same values as /proc/mounts, but otherwise
writable from userspace.

Every line written to /proc/mtab should be parsed into the fields, and
the mountpoints should be searched for a match, if a match is found, the
device and options fields are updated, otherwise the write is simply
ignored.

How does people like this idea? Should something more be done about the
options field? Should they be checked for obvious inconsistencies, or
should a write attempt to remount the filesystem with the new options?

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[Dominik Kubla]

On Thursday 27 February 2003 09:12, Kasper Dupont wrote:
> Dominik Kubla wrote:
> > I would recommend to replace /etc/mtab with a pseudo-FS like Sun did
> > for /etc/mnttab:
...
> How does that thing behave? I have considered a /proc/mtab implementation,
> that might be slightly similar. 

Quoting the Solaris 8 man page:

File Formats                                            mnttab(4)

NAME
     mnttab - mounted file system table

DESCRIPTION
     The file /etc/mnttab is really a file system  that  provides
     read-only  access  to  the table of mounted file systems for
     the current host. /etc/mnttab is read by programs using  the
     routines  described in getmntent(3C). Mounting a file system
     adds an entry to this table.  Unmounting  removes  an  entry
     from  this table. Remounting a file system causes the infor-
     mation in the mounted file system table  to  be  updated  to
     reflect any changes caused by the remount. The list is main-
     tained by the kernel in order of mount time.  That  is,  the
     first  mounted file system is first in the list and the most
     recently mounted file system is  last.  When  mounted  on  a
     mount  point  the file system appears as a regular file con-
     taining the current mnttab information.
[...]
NOTES
     The snapshot of the mnttab information is taken any  time  a
     read(2)  is  performed  at  offset  0 (the beginning) of the
     mnttab file. The file modification time returned by  stat(2)
     for  the  mnttab  file  is  the  time  of the last change to
     mounted file  system  information.  A  poll(2)  system  call
     requesting  a POLLRDBAND event can be used to block and wait
     for the system's mounted file system information to be  dif-
     ferent  from  the most recent snapshot since the mnttab file
     was opened.

Regards,
  Dominik Kubla
-- 
"What this  country needs is  a short, victorious war  to stem the  tide of
revolution." (V.K. von Plehve, Russian Minister  of Interior on the  eve of
the Russo-Japanese war.)

Re: About /etc/mtab and /proc/mounts

[Horst von Brand]

Dominik Kubla <dominik@kubla.de> said:
> On Thursday 27 February 2003 09:12, Kasper Dupont wrote:
> > Dominik Kubla wrote:
> > > I would recommend to replace /etc/mtab with a pseudo-FS like Sun did
> > > for /etc/mnttab:
> ...
> > How does that thing behave? I have considered a /proc/mtab implementation,
> > that might be slightly similar. 
> 
> Quoting the Solaris 8 man page:

I fail to see any significant difference to /proc/mounts (possibly expanded).
Sure, /proc is the wrong place for this kind of stuff, but...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: About /etc/mtab and /proc/mounts

[Christoph Hellwig]

On Thu, Feb 27, 2003 at 01:00:12PM -0300, Horst von Brand wrote:
> I fail to see any significant difference to /proc/mounts (possibly expanded).
> Sure, /proc is the wrong place for this kind of stuff, but...

In this rare case it's not.  /proc/mounts in fact is only a link
to /proc/self/mounts and that is needed because wecan have per-process
private namespace in Linux now.

(of course this drives the traditional /etc/mtab completly useless)

Re: About /etc/mtab and /proc/mounts

[Dominik Kubla]

On Thursday 27 February 2003 17:00, Horst von Brand wrote:
> Dominik Kubla <dominik@kubla.de> said:
> > Quoting the Solaris 8 man page:
>
> I fail to see any significant difference to /proc/mounts (possibly
> expanded). Sure, /proc is the wrong place for this kind of stuff, but...

Then i suggest that you re-read the mnttab(4) man page and compare
it to the Linux implementation.  :-)

Keep in mind that i only qouted some parts of the man page. Some thing
are just details (but as we all know details do matter):

[Linux]
# ls -l /proc mounts
lrwxrwxrwx    1 root     root           11 Feb 27 17:10 /proc/mounts -> 
self/mounts
# ls -l /proc/self/mounts
-r--r--r--    1 root     root            0 Feb 27 17:11 /proc/self/mounts
# wc -c /proc/self/mounts
   1058 /proc/self/mounts

[Solaris]
# ls -l /etc/mnttab
 r--r--r--   1 root         1178 Feb 25 16:26 /etc/mnttab
# wc -c /etc/mnttab
    1178 /etc/mnttab

The snapshot feature as quoted in the man page is not present under
Linux.  The poll(2) feature is not implemented. The solaris mntfs also
implements special ioctrls. Quoting the man page again:

[...]
IOCTLS
     The following ioctl(2) calls are supported:

     MNTIOC_NMOUNTS
           Returns the count of mounted resources in the  current
           snapshot in the uint32_t pointed to by arg.

     MNTIOC_GETDEVLIST
           Returns an array of uint32_t's that is twice  as  long
           as the length returned by MNTIOC_NMOUNTS. Each pair of
           numbers  is the major and minor device number for  the
           file  system at the corresponding  line in the current
           /etc/mnttab snapshot. arg points to the memory  buffer
           to receive the device number information.

    MNTIOC_SETTAG
           Sets a tag word into the options list  for  a  mounted
           file  system.  A tag is a notation that will appear in
           the options string of a mounted file system but it  is
           not recognized or interpreted by the file system code.
           arg points to a filled  in  mnttagdesc  structure,  as
           shown in the following example:

           uint_t  mtd_major; /* major number for mounted fs */
           uint_t  mtd_minor; /* minor number for mounted fs */
           char    *mtd_mntpt; /* mount point of file system */
           char    *mtd_tag;  /* tag to set/clear */

           If the tag already exists then it is marked as set but
           not re-added. Tags can be at most MAX_MNTOPT_TAG long.

     MNTIOC_CLRTAG
           Marks a tag in the options list  for  a  mounted  file
           system as not set. arg points to the same structure as
           MNTIOC_SETTAG, which identifies the  file  system  and
           tag to be cleared.
[...]

There is also an extended set of library functions to go along with that,
eg. getmntany(3), getextmntent(3), resetmnttab(3) and hasmntopt(3).

It is very helpful that one can get the time a mount happened! You can
not get this kind of information on Linux, neither from /etc/mtab nor from
/proc/self/mounts.

getextmnttab(3) also gives easy access to the device major and minor
number of the mount point.

So there are quite some differences between the Linux proc file and
the Solaris mntfs filesystem.  If these differences justify us doing it the
same way is debateable.

The strongest argument i see is: It's already been done this way by one
major Unix version, so why should Linux reinvent the wheel. Again.

Regards,
  Dominik
-- 
"What this  country needs is  a short, victorious war  to stem the  tide of
revolution." (V.K. von Plehve, Russian Minister  of Interior on the  eve of
the Russo-Japanese war.)

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

Dominik Kubla wrote:
> 
> So there are quite some differences between the Linux proc file and
> the Solaris mntfs filesystem.  If these differences justify us doing it the
> same way is debateable.
> 
> The strongest argument i see is: It's already been done this way by one
> major Unix version, so why should Linux reinvent the wheel. Again.

The reason for implementing that would IMHO not be to just get the features
that solaris has, but rather to get rid of /etc/mtab. I guess we all agree,
that a kernel implementation, that being a misc char device or a proc pseudo
file would be better than the current /etc/mtab file. But I think a kernel
implementation is also the most tricky. Bind mounting /proc/mounts onto
/etc/mtab would to some extent resemble the solaris implementation, but
there are noticable differences. I think one major question is if we can
actually make a kernel implementation that without help from userspace will
provide all the information that we have usually gotten from /etc/mtab. If
that is possible, I think we should aim for that and thereby make /etc/mtab
obsolete. Then we can eventually replace /etc/mtab with a symlink pointing
to /proc/mtab, /proc/self/mtab, or /proc/1/mtab. The fact that solaris makes
a snapshot of the mountpoints might be convenient, but really not that
important. The correct size reported by stat is also just a convenience. The
exact reporting of mtime is as already pointed out of real value to some
applications. And the ioctl to get major and minor is certainly helpful if
the device field is reused for other purposes in the case of bind mounts and
loopback mounts. Does solaris actually have those features, and what does
mnttab report in those cases? And while we are discussing bind mounts, there
is one feature that I have sometimes missed: A possibility to directly mount
a subdirectory of a filesystem without having to mount the root of that
filesystem first and use a bindmount afterwards.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

On Thu, 27 Feb 2003 20:47:05 +0100, Kasper Dupont said:

> mnttab report in those cases? And while we are discussing bind mounts, there
> is one feature that I have sometimes missed: A possibility to directly mount
> a subdirectory of a filesystem without having to mount the root of that
> filesystem first and use a bindmount afterwards.

Hmm.. so what you mean is being able to have a filesystem called (for example)
/somewhere, and being able to mount /somewhere/deep/path/like/this on a
mountpoint /wherever/else, but without having /somewhere mounted itself?
That looks *almost* doable, except that things like quotas or the free
block list would be a hassle if then you also went and mounted
/somewhere/deep/other/path on /something/else

Or did you want to do 'mount /somewhere/deep /wherever/else' when it's
/wherever that isn't actually mounted?  This looks more.. umm.. interesting,
as you could (for instance) use an automounter to mount /home/fred, /home/george
/home/sally, and not actually need a /home?  But don't current automounters
almost do this already?
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

Valdis.Kletnieks@vt.edu wrote:
> 
> On Thu, 27 Feb 2003 20:47:05 +0100, Kasper Dupont said:
> 
> > mnttab report in those cases? And while we are discussing bind mounts, there
> > is one feature that I have sometimes missed: A possibility to directly mount
> > a subdirectory of a filesystem without having to mount the root of that
> > filesystem first and use a bindmount afterwards.
> 
> Hmm.. so what you mean is being able to have a filesystem called (for example)
> /somewhere, and being able to mount /somewhere/deep/path/like/this on a
> mountpoint /wherever/else, but without having /somewhere mounted itself?

Yes.

> That looks *almost* doable, except that things like quotas or the free
> block list would be a hassle if then you also went and mounted
> /somewhere/deep/other/path on /something/else

It is doable. And you don't need to change the filesystems themselves.
In fact VFS has most of the support right now. It can be done in
userspace, I can do it by first mounting /somewhere then use --bind
and finally unomount /somewhere. The reason I brought it up is that
if we are going to change mount, we might want to add this feature,
and we should find some better strings for the device field in mtab.
Right now the sequence of commands I suggested would leave the name
of an unmounted filesystem in a device field in the mtab file. Perhaps
rather than writing the oldparth, it would be wiser to write
device:path in the device field, where path would be path relative to
the root of the filesystem. Then that same notation could be supported
by mount, and implemented by temporarily mounting the root of that
filesystem.

The only case that couldn't be done from userspace is mounting of the
root. Now some people might say nobody would need that feature, and it
could be done using initrd and some pivot_root stuff anyway. But in
fact a very similar feature already exists in the umsdos filesystem.
IMHO that feature should be removed from umsdos and reimplemented
using pivot_root instead. Then at the same time the hardcoded paths
could be changable through boot options, and the feature could become
filesystem independend.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[Miquel van Smoorenburg]

In article <3E5E91B2.8EACF7D0@daimi.au.dk>,
Kasper Dupont  <kasperd@daimi.au.dk> wrote:
>The only case that couldn't be done from userspace is mounting of the
>root. Now some people might say nobody would need that feature, and it
>could be done using initrd and some pivot_root stuff anyway.

Well, the kernel already has a simple rootfs built-in, on top of
which the real root filesystem gets mounted at boot-time.

Also POSIX makes a difference between '/' and '//'. '//' might
point to a different namespace.

So why not mount rootfs on '//', mount the real rootfilesystem
on //root, then chroot to //root (while keeping it possible to
chdir("//") ).

If mkdir and rmdir is added to rootfs, you could even mount //mtab.d
there, or //proc, or //devfs, whatever you want to have available
when the root filesystem is being fscked or not even mounted yet.
Perhaps the kernel should mount all those pseudofilesystems there
by default even.

Apollo/DomainOS had this '//' thing, used for something different
(it was the equivalent of their /net autofs mountpoint) but it
worked quite well and didn't get in the way of normal '/' operation.

Mike.
-- 
Anyone who is capable of getting themselves made President should
on no account be allowed to do the job -- Douglas Adams.

Re: About /etc/mtab and /proc/mounts

[Miles Bader]

miquels@cistron-office.nl (Miquel van Smoorenburg) writes:
> So why not mount rootfs on '//', mount the real rootfilesystem
> on //root, then chroot to //root (while keeping it possible to
> chdir("//") ).

Because it's _extremely_ common for `//...' to be generated by tools
constructing pathnames, when what's really meant is `/...'  (which is
fine, because normally it makes no difference).

> Apollo/DomainOS had this '//' thing, used for something different
> (it was the equivalent of their /net autofs mountpoint) but it
> worked quite well and didn't get in the way of normal '/' operation.

Really?  I'm skeptical...

-Miles
-- 
I'd rather be consing.

Re: About /etc/mtab and /proc/mounts

[DervishD]

    Hi Miles :)

 Miles Bader dixit:
> /var is clearly the right place for this; if /var isn't mounted
> initially, I'd suggest that mount should simply not update any file
> at that point, and the init-script that mounts /var can be
> responsible from propagating information from /proc/mounts to
> /var/whatever.

    In an embedded system I built a time ago, /etc/mtab was first a
symlink to /proc/mounts, but after a while I made it a symlink to
/var/run/mtab. It worked OK, AFAIK.

    Raúl

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

DervishD wrote:
> 
>     Hi Miles :)
> 
>  Miles Bader dixit:
> > /var is clearly the right place for this; if /var isn't mounted
> > initially, I'd suggest that mount should simply not update any file
> > at that point, and the init-script that mounts /var can be
> > responsible from propagating information from /proc/mounts to
> > /var/whatever.
> 
>     In an embedded system I built a time ago, /etc/mtab was first a
> symlink to /proc/mounts, but after a while I made it a symlink to
> /var/run/mtab. It worked OK, AFAIK.

Did mount actually update the mtab file? The version of mount on
my system would not.

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[DervishD]

    Hi Kasper :)

 Kasper Dupont dixit:
> >  Miles Bader dixit:
> > > /var is clearly the right place for this; if /var isn't mounted
> > > initially, I'd suggest that mount should simply not update any file
> > > at that point, and the init-script that mounts /var can be
> > > responsible from propagating information from /proc/mounts to
> > > /var/whatever.
> >     In an embedded system I built a time ago, /etc/mtab was first a
> > symlink to /proc/mounts, but after a while I made it a symlink to
> > /var/run/mtab. It worked OK, AFAIK.
> Did mount actually update the mtab file? The version of mount on
> my system would not.

    Of course not, it is just a symlink to a proc file ;))) I must
say that it worked OK but really only ext2 filesystems and a CDROM
were mounted, with default options. Don't know if the symlink would
have been worked if special options were used. Now that I remember,
we only use 'special' options for the CDROM (to allow mounting by
normal users) and the devpts (the permissions).

    Raúl

Re: About /etc/mtab and /proc/mounts

[Kasper Dupont]

DervishD wrote:
> 
>     Hi Kasper :)
> 
>  Kasper Dupont dixit:
> > > but after a while I made it a symlink to
> > > /var/run/mtab. It worked OK, AFAIK.
> > Did mount actually update the mtab file? The version of mount on
> > my system would not.
> 
>     Of course not, it is just a symlink to a proc file

But you just said it was a symlink to /var/run/mtab.
Did /var/run/mtab get updated?

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaarep@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

Re: About /etc/mtab and /proc/mounts

[DervishD]

    Hi Kasper :)

 Kasper Dupont dixit:
> > > > but after a while I made it a symlink to
> > > > /var/run/mtab. It worked OK, AFAIK.
> > > Did mount actually update the mtab file? The version of mount on
> > > my system would not.
> >     Of course not, it is just a symlink to a proc file
> But you just said it was a symlink to /var/run/mtab.

    Excuse me, I thought that you was talking about the /proc/mounts
symlink, and not /var/run/mtab. When the symlink was /var/run/mtab I
don't remeber if it was updated, but it should, because all worked
OK, I mean, all filesystems were correctly mounted. But anyway the
info provided by me is not reliable: we used the 'mount' command from
'asmutils' and I don't know how it managed /etc/mtab. All that
happened more than two years ago :(((, sorry. AFAIK, at some point of
the research, the mount command from busybox was used, too.

    Raúl

Re: About /etc/mtab and /proc/mounts

[DervishD]

    Hi Kasper :)

 Kasper Dupont dixit:
> Some more interesting cases are loopback mounts and bind mounts,
> in which case the device field is completely different.
[...]
> (And since I remember remount
> bugs in tmpfs in early 2.4 kernels, it is not going to get easier
> to put more requirements on the filesystem.)

    Not an easy fix, then. I've read the thread that this message
originated, and I think that the better solucion, in the short term I
mean, is to symlink /etc/mtab to a proper writeable place in the
filesystem. Anyway, I think that this kind of 'traditional' things
should go away and better solutions used instead. My particular
problem is that *I* don't have better solutions (at least
implemented...).

    Thanks a lot for the interest :)
    Raúl