All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan von Krawczynski <skraw@ithnet.com>
To: Jos Hulzink <josh@stack.nl>
Cc: alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org
Subject: Re: Are linux-fs's drive-fault-tolerant by concept?
Date: Sun, 20 Apr 2003 18:07:20 +0200	[thread overview]
Message-ID: <20030420180720.099b4c34.skraw@ithnet.com> (raw)
In-Reply-To: <200304192313.53955.josh@stack.nl>

On Sat, 19 Apr 2003 23:13:53 +0200
Jos Hulzink <josh@stack.nl> wrote:

> [...]
> 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.

Let me clarify again: I don't want fancy stuff inside the filesystem that
magically knows something about right-or-wrong. The only _very small_
enhancement I would like to see is: driver tells fs there is an error while
writing a certain block => fs tries writing the same data onto another block.
That's it, no magic, no RAID stuff. Very simple.

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

You are completely right, I don't want any more: nice management of an error a
low-level driver reports to the fs. Only I would like to see as an fs-answer to
this: ok, let's try another part of the media. Currently it just sinks like
titanic.

Regards,
Stephan

  reply	other threads:[~2003-04-20 15:55 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
2003-04-20 16:07     ` Stephan von Krawczynski [this message]
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=20030420180720.099b4c34.skraw@ithnet.com \
    --to=skraw@ithnet.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=josh@stack.nl \
    --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.