linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Berkey B Walker <berk@panix.com>
To: NeilBrown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: [md PATCH 00/16] bad block list management for md and RAID1
Date: Sun, 06 Jun 2010 20:28:04 -0400	[thread overview]
Message-ID: <4C0C3D14.6020206@panix.com> (raw)
In-Reply-To: <20100606235833.13302.60932.stgit@notabene.brown>

Excellent start Neil.  This will be much appreciated.
b-

NeilBrown wrote:
> 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(-)
>
>    

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

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-07  0:07 [md PATCH 00/16] bad block list management for md and RAID1 NeilBrown
2010-06-07  0:07 ` [md PATCH 01/16] md: beginnings of bad block management NeilBrown
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 03/16] md: don't allow arrays to contain devices with bad blocks 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 04/16] md: load/store badblock list from v1.x metadata 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 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 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 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 14/16] md/raid1: avoid writing to known-bad blocks on known-bad drives 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 16/16] md/raid1: Handle write errors by updating badblock log NeilBrown
2010-06-07  0:28 ` Berkey B Walker [this message]
2010-06-07 22:18   ` [md PATCH 00/16] bad block list management for md and RAID1 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=4C0C3D14.6020206@panix.com \
    --to=berk@panix.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /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).