All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Jackson <jerj@coplanar.net>
To: Brian Gerst <bgerst@didntduck.org>
Cc: root@chaos.analogic.com, 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 16:08:57 -0500	[thread overview]
Message-ID: <3AB67569.B203D75D@coplanar.net> (raw)
In-Reply-To: <Pine.LNX.3.95.1010319150027.9639A-100000@chaos.analogic.com> <3AB67134.762CFF32@didntduck.org>

Brian Gerst wrote:

> "Richard B. Johnson" wrote:
> >
> > On Mon, 19 Mar 2001, Otto Wyss wrote:
> >
> > > 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?
> > >
> >
> > Unix and other such variants have what's called a Virtual File System
> > (VFS).  The idea behind this is to keep as much recently-used file stuff
> > in memory so that the system can be as fast as if you used a RAM disk
> > instead of real physical (slow) hard disks. If you can't cope with this,
> > use DOS.
>
> At the very least the disk should be consistent with memory.  If the
> dirty pages aren't written back to the disk (but not necessarily removed
> from memory) after a reasonable idle period, then there is room for
> improvement.

They are.   If you leave your machine one for a minute or so (probably less is ok,
but I don't know) the kernel will flush dirty buffers... fsck will complain, but the
file's
*data* blocks will be on the disk.  There are way more reasons that this is a silly
and annoying thread.  You should read more about things like
asynchronous/synchronous filesystems,
lazy-write cacheing, etc, etc,.  If you know how to write software and/or configure
your system,
you can avoid all of these problems.  Or use a journaling filesystem ext3/xfs, etc.
But I tire of this...


  reply	other threads:[~2001-03-19 21:16 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 [this message]
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=3AB67569.B203D75D@coplanar.net \
    --to=jerj@coplanar.net \
    --cc=bgerst@didntduck.org \
    --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 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.