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 10:46:02 +0100 [thread overview]
Message-ID: <3E5DDE5A.1BCD0747@daimi.au.dk> (raw)
In-Reply-To: <buo65r6ru6h.fsf@mcspd15.ucom.lsi.nec.co.jp>
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(_);
next prev parent reply other threads:[~2003-02-27 9:35 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-19 11:21 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
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 [this message]
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=3E5DDE5A.1BCD0747@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome