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(-)
>
>
next prev 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).