All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: "Arkadiusz Miśkiewicz" <a.miskiewicz@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Bad block management - which mdadm?
Date: Tue, 25 Oct 2011 09:46:16 +1100	[thread overview]
Message-ID: <20111025094616.78384241@notabene.brown> (raw)
In-Reply-To: <201110242212.14934.a.miskiewicz@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

On Mon, 24 Oct 2011 22:12:14 +0200 Arkadiusz Miśkiewicz
<a.miskiewicz@gmail.com> wrote:

> 
> kernelnewbies.org reports such feature for 3.1 kernel
> 
> 1.9. Software RAID: Bad block management
> The MD layer (aka "Multiple Devices", aka software raid) has gained bad block 
> management support: bad blocks will be added to a list, and the system will 
> try not to use them. This feature requires an updated mdadm version.
> 
> Which mdadm supports that?
> 

mdadm-3.3 will support bad block management.
However it is not released yet.

You can get current code from

   git://neil.brown.name/mdadm  devel-3.3


It isn't released yet because

  1/ I haven't found/made time to work on mdadm and integrate support
     properly.
  2/ The kernel isn't really quite read for full support.

If you have a bad block list, then a write error will not fail the drive but
will record the location of the write error.
This might be what you want.  But if you have a hot-spare available it might
not be what you want - the current kernel code will never use a hot spare
until a drive fails really badly.

What it *should* do is "hot-replace".  i.e. recover the data on to a spare
without first removing the device with the bad block.  But the hot-replace
code isn't ready yet.

I expect hot-replace to be in linux-3.3 (for RAID4/5/6 at least) and I hope to
release mdadm-3.3 before then with full support for bad blocks and hot
replace.

For now if you use the devel-3.3 code to create a new array it will place a
bad-block-log on the array and the kernel will use that bad block log to
record failed blocks rather than failing the whole device.
If you want a device to be failed, you might have to explicitly do that
yourself with "mdadm /dev/mdX --fail /dev/sdY"

NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

      reply	other threads:[~2011-10-24 22:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-24 20:12 Bad block management - which mdadm? Arkadiusz Miśkiewicz
2011-10-24 22:46 ` NeilBrown [this message]

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=20111025094616.78384241@notabene.brown \
    --to=neilb@suse.de \
    --cc=a.miskiewicz@gmail.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 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.