From: David Mansfield <md@dm.cobite.com>
To: Guy <bugzilla@watkins-home.com>
Cc: 'Jure Pe_ar' <pegasus@nerv.eu.org>, linux-raid@vger.kernel.org
Subject: RE: raid5, media scans and stripe-wise resync
Date: Mon, 25 Oct 2004 16:35:32 -0400 [thread overview]
Message-ID: <1098736532.5399.52.camel@duxeon.cobite.com> (raw)
In-Reply-To: <200410252029.i9PKTEN26833@www.watkins-home.com>
On Mon, 2004-10-25 at 16:29, Guy wrote:
> Someone said:
> "In a hardware raid solution, you would only die if both bad sectors were in
> the same stripe, because when it encounters the bad sector, it doesn't eject
> the disk from the array. It reassigns the bad block, and resyncs just that
> stripe."
>
> Is a hardware solution, if 1 disk has a bad sector and another disk fails,
> game over. The only way I know to avoid this is RAID6. I hope RAID6
> becomes stable some day.
>
This is true, but has nothing to do with what I'm talking about.
Everyone is missing my point.
The point is that NEITHER DRIVE 'FAILS'. They just have unrecoverable
read errors, or bad sectors. As long as the two bad sectors are not in
the same stripe, you have not lost any data (theoretically, for s/w and
realistically for h/w).
It is a FACT that if a h/w raid controller encounters a bad sector, it
will *immediately* reassign it a reconstruct the stripe before moving
on. If there are no other bad sectors in that stripe, you are FINE.
Think about it. If later, (say 5 seconds later) another unrecoverable
error is encountered on a different disk, different stripe, it will be
handled fine, just as above.
Compare this to the S/W raid where the entire disk is ejected from the
array when the first bad sector is encountered. It cannot recover from
the 'two bad sectors on two disks in two different stripes' failure
scenario. H/W raid can.
David
> Guy
>
> -----Original Message-----
> From: linux-raid-owner@vger.kernel.org
> [mailto:linux-raid-owner@vger.kernel.org] On Behalf Of David Mansfield
> Sent: Monday, October 25, 2004 3:43 PM
> To: Jure Pe_ar
> Cc: linux-raid@vger.kernel.org
> Subject: Re: raid5, media scans and stripe-wise resync
>
> On Mon, 2004-10-25 at 13:19, Jure Pe_ar wrote:
> > On Mon, 25 Oct 2004 11:36:33 -0400
> > David Mansfield <md@dm.cobite.com> wrote:
> >
> > > 2) how can we force (or manually perform) a stripe-wise resync? is it
> > > possible to take the raid offline completely, read the data with dd,
> > > compute the parity manually, reassign the bad block using SCU and
> > > rewrite the parity block with dd then put the raid online again?
> >
> > In raid5 there's no real need for that. When you add disk back into array,
> > it should get fully resynced anyway.
> >
>
> Not quite. If disk 0 has a bad sector in stripe 0, and disk 1 has a bad
> sector in stripe 1, you will totally kill your array. It happens. It
> happened to us. Two bad sectors on two separate disks, but not on the
> same stripes.
>
> In a hardware raid solution, you would only die if both bad sectors were
> in the same stripe, because when it encounters the bad sector, it
> doesn't eject the disk from the array. It reassigns the bad block, and
> resyncs just that stripe.
>
> In the software situation, the entire disk will be ejected from the
> array after the first bad sector is detected. During resync, you will
> encounter the second bad sector (other drive), but because the
> information on the old disk 0 has been destroyed (the disk has been
> ejected from the array) your array is now dead.
>
> Does this make sense?
>
>
> > I've written a short blurb in my blog about a rather rude method to handle
> > misbehaving disks. Basically take it out of the array, run badblocks -w on
> > it for a week and if it's ok, put it back :)
> >
>
> Won't work if there are any bad sectors on any of the other disks. Even
> one other bad sector and your array is toast.
>
> David
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
next prev parent reply other threads:[~2004-10-25 20:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-25 15:36 raid5, media scans and stripe-wise resync David Mansfield
2004-10-25 17:19 ` Jure Pe_ar
2004-10-25 19:43 ` David Mansfield
2004-10-25 20:29 ` Guy
2004-10-25 20:35 ` David Mansfield [this message]
2004-10-25 20:48 ` Jure Pe_ar
2004-10-25 21:09 ` David Mansfield
2004-10-25 20:56 ` Guy
2004-10-25 22:02 ` Konstantin Olchanski
2004-10-26 2:34 ` Guy
2004-10-25 19:39 ` Bruce Lowekamp
2004-10-25 19:47 ` David Mansfield
2004-10-26 9:56 ` berk walker
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=1098736532.5399.52.camel@duxeon.cobite.com \
--to=md@dm.cobite.com \
--cc=bugzilla@watkins-home.com \
--cc=linux-raid@vger.kernel.org \
--cc=pegasus@nerv.eu.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 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).