linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephan von Krawczynski <skraw@ithnet.com>
To: John Bradford <john@grabjohn.com>
Cc: vda@port.imtp.ilyichevsk.odessa.ua, adilger@clusterfs.com,
	john@grabjohn.com, linux-kernel@vger.kernel.org
Subject: Re: Are linux-fs's drive-fault-tolerant by concept?
Date: Mon, 21 Apr 2003 12:25:44 +0200	[thread overview]
Message-ID: <20030421122544.5ae6bd6f.skraw@ithnet.com> (raw)
In-Reply-To: <200304210942.h3L9gZ1W000282@81-2-122-30.bradfords.org.uk>

On Mon, 21 Apr 2003 10:42:35 +0100 (BST)
John Bradford <john@grabjohn.com> wrote:

> > > > > > > I wonder whether it would be a good idea to give the linux-fs
> > > > > > > (namely my preferred reiser and ext2 :-) some
> > > > > > > fault-tolerance.
> > >
> > > I'm not against this in principle, but in practise it is almost
> > > useless. Modern disk drives do bad sector remapping at write time, so
> > > unless something is terribly wrong you will never see a write error
> > > (which is exactly the time that the filesystem could do such
> > > remapping).  Normally, you will only see an error like this at read
> > > time, at which point it is too late to fix.
> > 
> > It is *not* useless.
> > 
> > I have at least 4 disks with some bad sectors. Know what?
> > They are still in use in a school lab and as 'big diskettes'
> > (transferring movies etc). I refuse to dump them just because
> > 'todays disks are cheap'. I don't want my fs to die just because
> > these disks develop (ohhhh) a single new bad sector.
> 
> Read my previous posts.
> 
> A layer between device and filesystem can solve this.  It doesn't
> belong in the filesystem.

Yes it _can_, but is it _intelligent_ to do it there?


Ok, lets do it vice versa:

What do you need to do it?
- a free/allocated block list (for knowing where to put the mapped block)
- a bad block list for monitoring purposes
- spare blocks for really putting the data in

You say:
we re-invent/re-install the above information in a new layer. In this case you
have the problem to find known-to-be-free blocks. In other words, you have to
pre-alloc blocks (a fixed number) on the device, because else you interfer with
fs. fs must not see your mapped-blocks-in-spe, or else will use them sooner or
later. In other words you _waste_ them in case they are never needed.

I say:
we already have the needed information inside every fs, why not use it?
No space wasted, no double information.

If you say "it does not belong to fs" then please tell me: where in what bible
do you read that? Your argument sounds like "god-given" to me. Do you see
simple argueable technical issues?

I do not say it is _easy_ to do, I say it is an intelligent option. Note the
difference.

Regards,
Stephan


  reply	other threads:[~2003-04-21 10:14 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
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 [this message]
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
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=20030421122544.5ae6bd6f.skraw@ithnet.com \
    --to=skraw@ithnet.com \
    --cc=adilger@clusterfs.com \
    --cc=john@grabjohn.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    /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;
as well as URLs for NNTP newsgroup(s).