All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kasper Dupont <kasperd@daimi.au.dk>
To: Miles Bader <miles@gnu.org>
Cc: DervishD <raul@pleyades.net>,
	Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: About /etc/mtab and /proc/mounts
Date: Thu, 27 Feb 2003 09:25:45 +0100	[thread overview]
Message-ID: <3E5DCB89.9086582F@daimi.au.dk> (raw)
In-Reply-To: buon0kirym1.fsf@mcspd15.ucom.lsi.nec.co.jp

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(_);

  reply	other threads:[~2003-02-27  8:15 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-19 11:21 About /etc/mtab and /proc/mounts DervishD
2003-02-26  9:18 ` Kasper Dupont
2003-02-26 10:26   ` Miquel van Smoorenburg
2003-02-26 11:00     ` Olaf Dietsche
2003-02-26 11:14       ` Måns Rullgård
2003-02-26 11:44         ` Kasper Dupont
2003-02-26 12:16         ` Olaf Dietsche
2003-02-26 12:34           ` Måns Rullgård
2003-02-26 13:39             ` Olaf Dietsche
2003-02-26 13:54               ` Måns Rullgård
2003-02-26 14:23                 ` Olaf Dietsche
2003-02-27  4:14   ` Miles Bader
2003-02-27  6:40     ` Kasper Dupont
2003-02-27  7:03       ` Joseph Wenninger
2003-02-27  8:28         ` Kasper Dupont
2003-03-05  0:03           ` Jamie Lokier
2003-02-27  7:06       ` Miles Bader
2003-02-27  8:25         ` Kasper Dupont [this message]
2003-02-27  8:42           ` Miles Bader
2003-02-27  9:21             ` jw schultz
2003-02-27  9:49               ` Miles Bader
2003-02-27 23:33                 ` Kasper Dupont
2003-02-27 12:48               ` Denis Vlasenko
2003-02-27 23:28                 ` Kasper Dupont
2003-02-28  6:15                   ` Denis Vlasenko
2003-03-02 13:04               ` DervishD
2003-03-02 14:16                 ` Kasper Dupont
2003-03-03  1:04                   ` jw schultz
2003-03-03 12:22                     ` Kasper Dupont
2003-03-04  2:02                       ` jw schultz
2003-03-05 12:57                         ` Kasper Dupont
2003-03-06  1:18                           ` jw schultz
2003-03-06 23:30                             ` Kasper Dupont
2003-03-04 11:16                       ` DervishD
2003-03-04 11:08                   ` DervishD
2003-02-27  9:46             ` Kasper Dupont
2003-02-27  9:58               ` Miles Bader
2003-02-27 12:26                 ` Gabriel Paubert
2003-02-27  7:07       ` Joseph Wenninger
2003-02-27  7:08       ` Dominik Kubla
2003-02-27  8:12         ` Kasper Dupont
2003-02-27  9:11           ` Dominik Kubla
2003-02-27 16:00             ` Horst von Brand
2003-02-27 16:31               ` Christoph Hellwig
2003-02-27 16:40               ` Dominik Kubla
2003-02-27 19:47                 ` Kasper Dupont
2003-02-27 22:13                   ` Valdis.Kletnieks
2003-02-27 22:31                     ` Kasper Dupont
2003-02-27 23:54                       ` Miquel van Smoorenburg
2003-02-28  1:37                         ` Miles Bader
2003-03-02 12:53     ` DervishD
2003-03-02 14:00       ` Kasper Dupont
2003-03-04 11:02         ` DervishD
2003-03-04 12:09           ` Kasper Dupont
2003-03-04 14:53             ` DervishD
2003-03-02 12:51   ` DervishD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E5DCB89.9086582F@daimi.au.dk \
    --to=kasperd@daimi.au.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miles@gnu.org \
    --cc=raul@pleyades.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.