All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan von Krawczynski <skraw@ithnet.com>
To: John Bradford <john@grabjohn.com>
Cc: john@grabjohn.com, josh@stack.nl, alan@lxorguk.ukuu.org.uk,
	linux-kernel@vger.kernel.org
Subject: Re: Are linux-fs's drive-fault-tolerant by concept?
Date: Mon, 21 Apr 2003 11:32:36 +0200	[thread overview]
Message-ID: <20030421113236.3955d5e6.skraw@ithnet.com> (raw)
In-Reply-To: <200304201720.h3KHKG9A000716@81-2-122-30.bradfords.org.uk>

On Sun, 20 Apr 2003 18:20:16 +0100 (BST)
John Bradford <john@grabjohn.com> 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. 
> > > 
> > > That doesn't belong in the filesystem.
> > > 
> > > Imagine you have ten blocks free, and you allocate data to all of them
> > > in the filesystem.  The write goes to cache, and succeeds.
> > > 
> > > 30 seconds later, the write cache is flushed, and an error is reported
> > > back from the device.
> > 
> > And where's the problem?
> > Your case:
> > Immediate failure. Disk error.
> > 
> > My case:
> > Immediate failure. Disk error (no space left for replacement)
> > 
> > There's no difference.
> 
> In my case, the machine can continue as normal.  The filesystem is
> intact, (with no blocks free).  The block device driver has to cope
> with the error, which could be as simple as holding the data in RAM
> until an operator has been paged to replace the disk.

Forgive my ignorance, but I have not seen a case up to today where ide, aicX or
3ware has called me up for a replacement unit, written to it and been ok
afterwards. What the heck are you talking of?
I am not really interested in what a low-level driver could do unless there is
none that does it...
And again, how do you think this should work out on your _root_ partition? (see
below)

> In your case, the filesystem is no longer in a usable state.

I have yet to see an fs thats in a writeable state after the medium is full ...

>  If that
> was the root filesystem, the machine will, at best, probably go in to
> single user mode, with a read-only root filesystem.

How come?

> > Thing is: If there are 11 blocks free and not ten, then you fail
> 
> Wrong.  See above.

Please tell me when you were last "paged to replace the disk"? If you can't
tell me, then you know I am right by now.

> > and I succeed (if there's one bad block). You loose data, I don't.
> 
> John.

Regards,
Stephan


  reply	other threads:[~2003-04-21  9:20 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
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 [this message]
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=20030421113236.3955d5e6.skraw@ithnet.com \
    --to=skraw@ithnet.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=john@grabjohn.com \
    --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.