All of lore.kernel.org
 help / color / mirror / Atom feed
From: Otto Wyss <otto.wyss@bluewin.ch>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Linux should better cope with power failure
Date: Mon, 19 Mar 2001 23:35:55 +0100	[thread overview]
Message-ID: <3AB689CC.FE5A8AAB@bluewin.ch> (raw)

Jeremy Jackson wrote:
> 
> 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
[..]
> > > 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

There was at least 15min I waited without doing anything (how could I
without any imput device). I was editing a file with vim and the usual
bunch of demons where running mostly doing nothing. I don't know if all
the complains from fsck where due to open files or dirty cache pages. I
wouldn't complain if there was any heavy activity but there was allmost none.

> *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...

So in real live you would propose to put fences and nets everywhere to
prevent children from possibly falling in abyses?

O. Wyss

             reply	other threads:[~2001-03-19 22:37 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-19 22:35 Otto Wyss [this message]
2001-03-19 23:12 ` Linux should better cope with power failure John R Lenton
  -- strict thread matches above, loose matches on Subject: below --
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
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 21:16 Torrey Hoffman
2001-03-19 22:28 ` Stephen Satchell
2001-03-19 23:05   ` Andre Hedrick
2001-03-19 19:46 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
2001-03-19 23:07   ` Werner Almesberger
2001-03-19 20:19 ` William T Wilson

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=3AB689CC.FE5A8AAB@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 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.