linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Mansfield <md@dm.cobite.com>
To: linux-raid@vger.kernel.org
Subject: raid5, media scans and stripe-wise resync
Date: Mon, 25 Oct 2004 11:36:33 -0400	[thread overview]
Message-ID: <1098718593.5399.29.camel@duxeon.cobite.com> (raw)

Hi everyone,

After a few recent severe raid failures (one linux md, one 3ware), my
understanding and fear about linux md is greatly increased.  Single
sector unrecoverable errors are doing us in!

To alleviate these fears, we (my coworkers and I) believe we need to
start a policy of conducting a 'background media scan' of the actual
underlying physical devices in a raid 5.  This is easily accomplished on
the 3ware (it's built in), but we are struggling with linux md.

A utility called SCU, http://www.bit-net.com/%7Ermiller/scu.html, will
allow us to scan the media, and, if necessary, reassign the bad blocks. 
We have used this on scsi disks before, it seems to work, as a lowlevel
tool.

However! If two bad blocks are discovered on two different disks in the
raid 5 (even if the bad blocks are in different stripes), we will be
screwed, because the raid system will kick out the disk immediately when
the first bad sector is found, and then reconstruction will fail when
the second bad sector is found.  screwed.

Which brings me (finally) to my questions:

1) does linux md have a plan for integrating background media scanning
and automatic sector reassignment like hardware solutions have?

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?

If #2 is possible, I'm sure a quick-and-dirty perl script could be
created to do the work, which I'd be happy to do, if it's theoretically
doable.

Thanks,
David



             reply	other threads:[~2004-10-25 15:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-25 15:36 David Mansfield [this message]
2004-10-25 17:19 ` raid5, media scans and stripe-wise resync Jure Pe_ar
2004-10-25 19:43   ` David Mansfield
2004-10-25 20:29     ` Guy
2004-10-25 20:35       ` David Mansfield
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=1098718593.5399.29.camel@duxeon.cobite.com \
    --to=md@dm.cobite.com \
    --cc=linux-raid@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 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).