From: Jos Hulzink <josh@stack.nl>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Stephan von Krawczynski <skraw@ithnet.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Are linux-fs's drive-fault-tolerant by concept?
Date: Sat, 19 Apr 2003 23:13:53 +0200 [thread overview]
Message-ID: <200304192313.53955.josh@stack.nl> (raw)
In-Reply-To: <1050766175.3694.4.camel@dhcp22.swansea.linux.org.uk>
On Saturday 19 Apr 2003 17:29, Alan Cox wrote:
> On Sad, 2003-04-19 at 17:04, Stephan von Krawczynski wrote:
> > after shooting down one of this bloody cute new very-big-and-poor IDE
> > drives today I wonder whether it would be a good idea to give the
> > linux-fs (namely my preferred reiser and ext2 :-) some fault-tolerance. I
> > remember there have been some discussions along this issue some time ago
> > and I guess remembering that it was decided against because it should be
> > the drivers issue to give the fs a clean space to live, right?
>
> Sometimes disks just go bang. They seem to do it distressingly more
> often nowdays which (while handy for criminals and pirates) is annoying
> for the rest of us. Putting magic in the file system to handle this is
> hard to do well, and at best you get things like ext2/ext3 have now -
> the ability to recover data in the event of some corruption, unless you
> get into really fancy stff.
Basically, disks 1) die or 2) get bad sectors. Unfortunately, all disk
problems I had so far belong in the 1st category. There is nothing to recover
there, or it must be done by professionals (electrical / mechanical
reconstruction of the drive) Talking about the second category: any disk has
ECC these days, and recoverable errors (sector dying, but data valid) are
detectable and can be handled (badblocks + sector remapping). This all has
nothing to do with filesystems.
Now there is one error left: The unrecoverable data error. Basically this
means you can't trust the data of an entire sector. It might be possible that
only one bit is wrong, true, but for any read/write mounted filesystem, you
don't want to continue beyond this point before a decent filesystem check has
been done. It might be an option to mount a partition readonly as soon as
errors are discovered (don't make the mess bigger than it is already).
Fault tolerance in a filesystem layer means in practical terms that you are
guessing what a filesystem should look like, for the disk doesn't answer that
question anymore. IMHO you don't want that to be done automagically, for it
might go right sometimes, but also might trash everything on RW filesystems.
Fault tolerance OK, but the fs layer should only detect errors reported by the
lower level drivers and handle them gracefully (which is something that might
need impovement a little for some fs drivers), or else trust the data it
gets.
Jos
next prev parent reply other threads:[~2003-04-19 20:56 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-19 16:04 Are linux-fs's drive-fault-tolerant by concept? Stephan von Krawczynski
2003-04-19 15:29 ` Alan Cox
2003-04-19 17:00 ` Stephan von Krawczynski
2003-04-19 22:04 ` Alan Cox
2003-04-20 16:24 ` Stephan von Krawczynski
2003-04-20 13:59 ` John Bradford
2003-04-20 16:55 ` Stephan von Krawczynski
2003-04-20 17:12 ` John Bradford
2003-04-20 17:21 ` Stephan von Krawczynski
2003-04-20 18:48 ` Alan Cox
2003-04-20 20:00 ` John Bradford
2003-04-21 1:51 ` jw schultz
2003-04-19 21:13 ` Jos Hulzink [this message]
2003-04-20 16:07 ` Stephan von Krawczynski
2003-04-20 16:40 ` John Bradford
2003-04-20 17:01 ` Stephan von Krawczynski
2003-04-20 17:20 ` John Bradford
2003-04-21 9:32 ` Stephan von Krawczynski
2003-04-21 9:55 ` John Bradford
2003-04-21 11:24 ` Stephan von Krawczynski
2003-04-21 11:50 ` Alan Cox
2003-04-21 12:14 ` John Bradford
2003-04-19 16:22 ` John Bradford
2003-04-19 16:36 ` Russell King
2003-04-19 16:45 ` John Bradford
2003-04-19 16:52 ` Stephan von Krawczynski
2003-04-19 20:04 ` John Bradford
2003-04-19 20:33 ` Andreas Dilger
2003-04-21 9:25 ` Denis Vlasenko
2003-04-21 9:42 ` John Bradford
2003-04-21 10:25 ` Stephan von Krawczynski
2003-04-21 10:50 ` John Bradford
2003-04-19 20:38 ` Stephan von Krawczynski
2003-04-20 14:21 ` John Bradford
2003-04-21 9:09 ` Denis Vlasenko
2003-04-21 9:35 ` John Bradford
2003-04-21 11:03 ` Stephan von Krawczynski
2003-04-21 12:04 ` John Bradford
2003-04-21 11:22 ` Denis Vlasenko
2003-04-21 11:46 ` Stephan von Krawczynski
2003-04-21 12:13 ` John Bradford
2003-04-19 20:05 ` John Bradford
2003-04-19 23:13 ` Arnaldo Carvalho de Melo
2003-04-19 17:54 ` Felipe Alfaro Solana
2003-04-25 0:07 ` Stewart Smith
2003-04-25 0:52 ` Richard B. Johnson
2003-04-25 7:13 ` John Bradford
[not found] ` <20030419161011$0136@gated-at.bofh.it>
2003-04-19 17:18 ` Florian Weimer
2003-04-19 18:07 ` Stephan von Krawczynski
2003-04-19 18:41 ` Dr. David Alan Gilbert
2003-04-19 20:56 ` Helge Hafting
2003-04-19 21:15 ` Valdis.Kletnieks
2003-04-20 10:51 ` Helge Hafting
2003-04-20 19:04 ` Valdis.Kletnieks
2003-04-19 21:57 ` Alan Cox
2003-04-20 10:09 ` Geert Uytterhoeven
2003-04-21 8:37 ` Denis Vlasenko
2003-05-05 12:38 ` Pavel Machek
2003-04-19 22:02 ` Alan Cox
2003-04-20 8:41 ` Arjan van de Ven
2003-04-25 0:11 ` Stewart Smith
-- strict thread matches above, loose matches on Subject: below --
2003-04-20 15:06 Chuck Ebbert
2003-04-20 15:19 ` John Bradford
2003-04-20 17:03 Chuck Ebbert
2003-04-20 17:25 ` John Bradford
2003-04-20 17:28 Chuck Ebbert
2003-04-21 9:36 ` Stephan von Krawczynski
2003-04-20 17:28 Chuck Ebbert
2003-04-20 17:44 Chuck Ebbert
2003-04-20 17:44 Chuck Ebbert
[not found] <mail.linux.kernel/20030420185512.763df745.skraw@ithnet.com>
[not found] ` <03Apr21.020150edt.41463@gpu.utcc.utoronto.ca>
2003-04-21 11:19 ` Stephan von Krawczynski
2003-04-21 11:52 ` Alan Cox
2003-04-21 14:14 ` Valdis.Kletnieks
2003-05-06 7:03 ` Mike Fedyk
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=200304192313.53955.josh@stack.nl \
--to=josh@stack.nl \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=skraw@ithnet.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