From: Ben Ford <ben@kalifornia.com>
To: Jeremy Jackson <jerj@coplanar.net>
Cc: root@chaos.analogic.com, Brian Gerst <bgerst@didntduck.org>,
Otto Wyss <otto.wyss@bluewin.ch>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Linux should better cope with power failure
Date: Mon, 19 Mar 2001 07:14:28 -0800 [thread overview]
Message-ID: <3AB62254.5CB508AB@kalifornia.com> (raw)
In-Reply-To: <Pine.LNX.3.95.1010319162020.12070A-100000@chaos.analogic.com> <3AB6850A.4D7FDA26@coplanar.net>
> Actually, I think /etc/mtab is not needed at all. Originally, UNIX
> used to put as much onto the disk (and not in "core") as possible.
> so much state information related only to one boot-cycle was
> taken out of kernel and stored on disk. /var/run/utmp, /etc/mtab,
> , rmtab, and many others. all are invalidated by a reboot, and are yet
> stored
> in non-volatile storage. kernel memory is not swappable, so they manually
> separated out the minimum needed in core.
>
> Linux currently has a lot of this info in core, and maintains the disk files
> for backwards compatibility. in the case of /etc/mtab, I believe
> /proc/mounts
> has the same info. It appears to be in the same format as /etc/mtab,
> so most of the groundwork has already been done.
> i've considered trying just changing /etc/mtab to /proc/mounts in some
> utilities, to remove the need for read-write root. This (and other cases)
> would guarantee consistency (look at /etc/mtab after restart in single
> user more - ugh)
It has been suggested to ln -sf /proc/mounts /etc/mtab. Linus has said this, I
believe.
-b
next prev parent reply other threads:[~2001-03-19 23:11 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-19 19:46 Linux should better cope with power failure Otto Wyss
2001-03-19 19:59 ` Charles Cazabon
2001-03-19 20:15 ` Richard B. Johnson
2001-03-19 20:51 ` Brian Gerst
2001-03-19 21:08 ` Jeremy Jackson
2001-03-19 21:35 ` Richard B. Johnson
2001-03-19 21:59 ` Brian Gerst
2001-03-19 22:15 ` Jeremy Jackson
2001-03-19 15:14 ` Ben Ford [this message]
2001-03-19 23:07 ` Werner Almesberger
2001-03-19 20:19 ` William T Wilson
-- strict thread matches above, loose matches on Subject: below --
2001-03-19 21:16 Torrey Hoffman
2001-03-19 22:28 ` Stephen Satchell
2001-03-19 23:05 ` Andre Hedrick
2001-03-19 22:11 Stephen Gutknecht (linux-kernel)
2001-03-19 22:39 ` Otto Wyss
2001-03-20 21:38 ` H. Peter Anvin
2001-03-19 22:35 Otto Wyss
2001-03-19 23:12 ` John R Lenton
2001-03-23 15:28 David Balazic
2001-03-23 18:22 ` Gerhard Mack
2001-03-26 9:34 ` David Balazic
2001-03-23 19:29 ` Otto Wyss
2001-03-23 22:41 ` David Ford
2001-03-24 8:44 ` Otto Wyss
2001-03-24 9:47 ` David Ford
2001-03-24 10:28 ` Otto Wyss
2001-03-26 10:22 ` David Balazic
2001-03-26 10:17 ` David Balazic
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=3AB62254.5CB508AB@kalifornia.com \
--to=ben@kalifornia.com \
--cc=bgerst@didntduck.org \
--cc=jerj@coplanar.net \
--cc=linux-kernel@vger.kernel.org \
--cc=otto.wyss@bluewin.ch \
--cc=root@chaos.analogic.com \
/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