public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Brian <hiryuu@envisiongames.net>,
	linux-kernel@vger.kernel.org, Stephen Tweedie <sct@redhat.com>
Subject: Re: Disk errors and Reiserfs
Date: Tue, 18 Sep 2001 11:17:02 +0100	[thread overview]
Message-ID: <20010918111702.A12248@redhat.com> (raw)
In-Reply-To: <200109162329.f8GNTY918084@demai05.mw.mediaone.net> <E15imSi-00068f-00@the-village.bc.nu>
In-Reply-To: <E15imSi-00068f-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Mon, Sep 17, 2001 at 01:40:36AM +0100

Hi,

On Mon, Sep 17, 2001 at 01:40:36AM +0100, Alan Cox wrote:
> > My issue, though, is Linux did not handle it well.  Userspace actually has 
> > an 'EIO' error code for this situation but, instead, any program touching 
> > the mounted partition hung in a D state.
> 
> Thats a reiserfs property and one you'll find in pretty much any other
> fs.

No --- ext2 and ext3 will propagate EIO up to the application.  We've
also spent a lot of effort making sure that ext2 won't ever panic even
if the IO succeeds but returns bogus data (disk, cable or controller
faults).  Disk failures should never cause process kernel hangs, any
more than bogus network packets should.

> Killing the process isnt neccessary, its been halted in its tracks. As to
> a clean shutdown - no chance. You've just hit a disk failure, the on disk
> state is not precisely known, writes have been lost. Nothing is going to
> make a clean shutdown possible under such circumstances.

Why not?  ext2 lets you select between three behaviours on detecting
such an error: continue (the fs is marked as having errors and will be
fscked on the next boot, as long as we can write the error flag to the
superblock); remount-readonly (we fail the IO and force the fs
readonly, but otherwise continue as above); or panic immediately.  As
long as you've selected continue or continue-ro, you should be able to
unmount the disk as soon as you've killed any processes still
accessing it.  I've also spent a lot of effort making sure that the
backoff-and-remount-readonly code in ext3 is solid, too.  I don't 
regard a kernel lockup as a necessary response to disk failure.

Cheers,
 Stephen

      parent reply	other threads:[~2001-09-18 10:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-16 23:29 Disk errors and Reiserfs Brian
2001-09-17  0:40 ` Alan Cox
2001-09-17  2:32   ` Brian
2001-09-17 10:45   ` Guus Sliepen
2001-09-18 10:17   ` Stephen C. Tweedie [this message]

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=20010918111702.A12248@redhat.com \
    --to=sct@redhat.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=hiryuu@envisiongames.net \
    --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