From: Otto Wyss <otto.wyss@bluewin.ch>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Linux should better cope with power failure
Date: Mon, 19 Mar 2001 20:46:59 +0100 [thread overview]
Message-ID: <3AB66233.B85881C7@bluewin.ch> (raw)
Lately I had an USB failure, leaving me without any access to my system
since I only use an USB-keyboard/-mouse. All I could do in that
situation was switching power off and on after a few minutes of
inactivity. From the impression I got during the following startup, I
assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power
failiure or manually switching it off. Not even if there wasn't any
activity going on.
Shouldn't a good system allways try to be on the save side? Shouldn't
Linux try to be more fail save? There is currently much work done in
getting high performance during high activity but it seems there is no
work done at all in getting a save system during low/no activity. I
think this is a major drawback and should be addressed as fast as
possible. Bringing a system to save state should allway have a high priority.
How could this be accomplished:
1. Flush any dirty cache pages as soon as possible. There may not be any
dirty cache after a certain amount of idle time.
2. Keep open files in a state where it doesn't matter if they where
improperly closed (if possible).
3. Swap may not contain anything which can't be discarded. Otherwise
swap has to be treated as ordinary disk space.
These actions are not filesystem dependant. It might be that certain
filesystem cope better with power failiure than others but still it's
much better not to have errors instead to fix them.
Don't we tell children never go close to any abyss or doesn't have
alpinist a saying "never go to the limits"? So why is this simple rule
always broken with computers?
O. Wyss
next reply other threads:[~2001-03-19 19:48 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-19 19:46 Otto Wyss [this message]
2001-03-19 19:59 ` Linux should better cope with power failure 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
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=3AB66233.B85881C7@bluewin.ch \
--to=otto.wyss@bluewin.ch \
--cc=linux-kernel@vger.kernel.org \
/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