linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: linux-raid@vger.kernel.org
Subject: [md PATCH 00/16] bad block list management for md and RAID1
Date: Mon, 07 Jun 2010 10:07:53 +1000	[thread overview]
Message-ID: <20100606235833.13302.60932.stgit@notabene.brown> (raw)

In the spirit of "release early" I thought I would post some patches
that I have been working on lately.

Please don't try these on a system with valuable data - they are very
early code and will probably do the wrong thing.

The goal of these patches is to add a 'bad block list' to each device
and use it to allow us to fail single blocks rather than whole
devices.

This is particularly useful in arrays will multiple redundancy
(e.g. RAID6 or 3-device RAID1).  In such cases, bad blocks in
different places on different devices can leave an array that still
has at-least single redundancy on all stripes.  Without this support,
such arrays could become non-fuinctional.

This is also a necessary preparation to being able to support
'hot-replace' where we build a new device while the old device is
still in service.  Such a process is only really needed if the old
device is potentially faulty, and having the bad-block-list in place
allows it to continue to provide the best service it can even when it
cannot provide 100% service.

These patches have only seen limited testing, and are posted primarily
for review rather than testing, though testing is always valuable,
especially if you use the md/faulty module to simulate errors, or have
a drive that provides you with real errors...

This series provides infrastructure and integration into raid1.c only.
raid5.c and raid10.c support are still to be written.

NeilBrown


---

NeilBrown (16):
      md: beginnings of bad block management.
      md/bad-block-log: add sysfs interface for accessing bad-block-log.
      md: don't allow arrays to contain devices with bad blocks.
      md: load/store badblock list from v1.x metadata
      md: reject devices with bad blocks and v0.90 metadata.
      md/raid1: clean up read_balance.
      md: simplify raid10 read_balance
      md/raid1: avoid reading from known bad blocks.
      md/raid1: avoid reading known bad blocks during resync
      md: add 'write_error' flag to component devices.
      md/multipath: discard ->working_disks in favour of ->degraded
      md: make error_handler functions more uniform and correct.
      md: make it easier to wait for bad blocks to be acknowledged.
      md/raid1: avoid writing to known-bad blocks on known-bad drives.
      md/raid1: clear bad-block record when write succeeds.
      md/raid1:  Handle write errors by updating badblock log.


 drivers/md/dm-raid456.c   |    6 
 drivers/md/md.c           |  725 +++++++++++++++++++++++++++++++++++++++++++--
 drivers/md/md.h           |   76 ++++-
 drivers/md/multipath.c    |   60 ++--
 drivers/md/multipath.h    |    1 
 drivers/md/raid1.c        |  714 +++++++++++++++++++++++++++++++++++---------
 drivers/md/raid1.h        |   14 +
 drivers/md/raid10.c       |  123 ++++----
 drivers/md/raid5.c        |   48 ++-
 include/linux/raid/md_p.h |   13 +
 10 files changed, 1475 insertions(+), 305 deletions(-)

-- 
Signature


             reply	other threads:[~2010-06-07  0:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-07  0:07 NeilBrown [this message]
2010-06-07  0:07 ` [md PATCH 02/16] md/bad-block-log: add sysfs interface for accessing bad-block-log NeilBrown
2010-06-07  0:07 ` [md PATCH 01/16] md: beginnings of bad block management NeilBrown
2010-06-07  0:07 ` [md PATCH 04/16] md: load/store badblock list from v1.x metadata NeilBrown
2010-06-07  0:07 ` [md PATCH 03/16] md: don't allow arrays to contain devices with bad blocks NeilBrown
2010-06-07  0:07 ` [md PATCH 06/16] md/raid1: clean up read_balance NeilBrown
2010-06-07  0:07 ` [md PATCH 07/16] md: simplify raid10 read_balance NeilBrown
2010-06-07  0:07 ` [md PATCH 05/16] md: reject devices with bad blocks and v0.90 metadata NeilBrown
2010-06-07  0:07 ` [md PATCH 08/16] md/raid1: avoid reading from known bad blocks NeilBrown
2010-06-07  0:07 ` [md PATCH 09/16] md/raid1: avoid reading known bad blocks during resync NeilBrown
2010-06-07  0:07 ` [md PATCH 11/16] md/multipath: discard ->working_disks in favour of ->degraded NeilBrown
2010-06-07  0:07 ` [md PATCH 12/16] md: make error_handler functions more uniform and correct NeilBrown
2010-06-07  0:07 ` [md PATCH 10/16] md: add 'write_error' flag to component devices NeilBrown
2010-06-07  0:07 ` [md PATCH 13/16] md: make it easier to wait for bad blocks to be acknowledged NeilBrown
2010-06-07  0:07 ` [md PATCH 15/16] md/raid1: clear bad-block record when write succeeds NeilBrown
2010-06-07  0:07 ` [md PATCH 14/16] md/raid1: avoid writing to known-bad blocks on known-bad drives NeilBrown
2010-06-07  0:07 ` [md PATCH 16/16] md/raid1: Handle write errors by updating badblock log NeilBrown
2010-06-07  0:28 ` [md PATCH 00/16] bad block list management for md and RAID1 Berkey B Walker
2010-06-07 22:18   ` Stefan /*St0fF*/ Hübner
2010-06-17 12:48 ` Brett Russ
2010-06-17 15:53   ` Graham Mitchell
2010-06-18  3:58     ` Neil Brown
2010-06-18  4:30       ` Graham Mitchell
2010-06-18  3:23   ` Neil Brown
     [not found]     ` <4C1BABC4.3020008@tmr.com>
2010-06-29  5:06       ` Neil Brown
2010-06-29 16:54         ` Bill Davidsen

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=20100606235833.13302.60932.stgit@notabene.brown \
    --to=neilb@suse.de \
    --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).