All of lore.kernel.org
 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 04/16] md: load/store badblock list from v1.x metadata 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 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 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 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 11/16] md/multipath: discard ->working_disks in favour of ->degraded NeilBrown
2010-06-07  0:07 ` [md PATCH 16/16] md/raid1: Handle write errors by updating badblock log 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: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 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.