All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maurilio Longo <maurilio.longo@libero.it>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: Guy Watkins <guy@watkins-home.com>, linux-raid@vger.kernel.org
Subject: Re: Bad blocks are killing us!
Date: Tue, 16 Nov 2004 17:28:47 +0100	[thread overview]
Message-ID: <419A2ABF.623A126A@libero.it> (raw)
In-Reply-To: 16793.11589.337840.541169@cse.unsw.edu.au

Neil Brown ha scritto:

> On Monday November 15, guy@watkins-home.com wrote:
> > Neil,
> >       This is a private email.  You can post it if you want.
> snip
> >
> >       Anyway, in the past there have been threads about correcting bad
> > blocks automatically within md.  I think a RAID1 patch was created that will
> > attempt to correct a bad block automatically.  Is it likely that you will
> > pursue this for RAID5 and maybe RAID6?  I hope so.
>
> My current plans for md are:

[...]

>
>  2/ Look at recovering from failed reads that can be fixed by a
>     write.  I am considering leveraging the "bitmap resync" stuff for
>     this.  With the bitmap stuff in place, you can let the kernel kick
>     out a drive that has a read error, let user-space have a quick
>     look at the drive and see if it might be a recoverable error, and
>     then give the drive back to the kernel.  It will then do a partial
>     resync based on the bitmap information, thus writing the bad
>     blocks, and all should be fine.  This would mean re-writing
>     several megabytes instead of a few sectors, but I don't think that
>     is a big cost.  There are a few issues that make it a bit less
>     trivial than that, but it will probably be my starting point.
>     The new "faulty" personality will allow this to be tested easily.
>

I think 2/ should go unattended for at least a few retries, then, if they all
fail, kick-out disk and/or call user-space program to see what's going on, I say
this because an occasional read error should not kick-out a disk or require user
intervention to fix it (as it is now).

And it seems to me that new disks have a lot of badsectors regardless their brand.

just my .02 euro cents :)

regards.


--
 __________
|  |  | |__| md2520@mclink.it
|_|_|_|____| Team OS/2 Italia



  reply	other threads:[~2004-11-16 16:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200411150522.iAF5MNN18341@www.watkins-home.com>
2004-11-15 22:27 ` Bad blocks are killing us! Neil Brown
2004-11-16 16:28   ` Maurilio Longo [this message]
2004-11-16 18:18   ` Guy
2004-11-16 23:04     ` Neil Brown
2004-11-16 23:07       ` Guy
2004-11-17 13:21         ` Badstripe proposal (was Re: Bad blocks are killing us!) David Greaves
2004-11-18  9:59           ` Maurilio Longo
2004-11-18 10:29             ` Robin Bowes
2004-11-19 17:12             ` Jure Pe_ar
2004-11-20 13:15               ` Maurilio Longo
2004-11-21 18:23                 ` Jure Pe_ar
2004-11-16 23:29       ` Bad blocks are killing us! dean gaudet
2004-11-17 21:58   ` Bruce Lowekamp
2004-11-18  1:46     ` Guy Watkins
2004-11-18 16:03       ` Bruce Lowekamp
2004-11-19 18:47       ` Dieter Stueken
2004-11-22  8:22       ` Dieter Stueken
2004-11-22  9:17         ` Guy

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=419A2ABF.623A126A@libero.it \
    --to=maurilio.longo@libero.it \
    --cc=guy@watkins-home.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@cse.unsw.edu.au \
    /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.