linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Greaves <david@dgreaves.com>
To: Mario 'BitKoenig' Holbe <Mario.Holbe@TU-Ilmenau.DE>
Cc: linux-raid@vger.kernel.org,
	Jon Nelson <jnelson-linux-raid@jamponi.net>,
	neilb@suse.de
Subject: Re: Proactive Drive Replacement
Date: Tue, 21 Oct 2008 09:38:17 +0100	[thread overview]
Message-ID: <48FD94F9.3060400@dgreaves.com> (raw)
In-Reply-To: <gdj1c4$8nf$1@ger.gmane.org>

Mario 'BitKoenig' Holbe wrote:
> Jon Nelson <jnelson-linux-raid@jamponi.net> wrote:
>> I was wondering about proactive drive replacement.
> [bitmaps, raid1 drive to replace and new drive, ...]
> 
> I belive to remember a HowTo going over this list somewhere in the past
> (early bitmap times?) which was recommending exactly your way.
> 
>> The problem I see with the above is the creation of the raid1 which
>> overwrites the superblock. Is there some way to avoid that (--build?)?
> 
> You can build a RAID1 without superblock.

How nice, an independent request for a feature just a few days later...

See:
   "non-degraded component replacement was Re: Distributed spares"
http://marc.info/?l=linux-raid&m=122398583728320&w=2

It references Dean Gaudet's work which explains why the above scenario, although
it seems OK at first glance, isn't good enough.

The main issue is that the drive being replaced almost certainly has a bad
block. This block could be recovered from the raid5 set but won't be.
Worse, the mirror operation may just fail to mirror that block - leaving it
'random' and thus corrupt the set when replaced.
Of course this will work in the happy path ... but raid is about correct
behaviour in the unhappy path.

If you could force the mirroring to complete and note the non-mirrored blocks
then you could fix it by identifying the bad/unwritten block on the new device
in a raid set and manually set the bitmap for the area around that block to be
'dirty' and force it to be rebuilt from the remaining disks.

Actually, this would be a nice thing to do as a subset of the feature to force a
re-write of SMART identified badblocks using parity calculated values.

David


-- 
"Don't worry, you'll be fine; I saw it work in a cartoon once..."

  reply	other threads:[~2008-10-21  8:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-20 17:35 Proactive Drive Replacement Jon Nelson
2008-10-20 22:40 ` Mario 'BitKoenig' Holbe
2008-10-21  8:38   ` David Greaves [this message]
2008-10-21 13:05     ` Jon Nelson
2008-10-21 13:36       ` David Greaves
2008-10-21 13:50       ` David Lethe
2008-10-21 14:11         ` Mario 'BitKoenig' Holbe
2008-10-21 15:13           ` David Lethe
2008-10-21 15:30             ` Mario 'BitKoenig' Holbe
2008-10-21 19:39         ` David Greaves
2008-10-21 13:57     ` Mario 'BitKoenig' Holbe
2008-10-21 17:29       ` David Greaves
2008-10-24  5:57     ` Luca Berra
2008-10-24  8:09       ` David Greaves
2008-10-25 13:20         ` Luca Berra
2008-10-25 16:33           ` David Greaves

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=48FD94F9.3060400@dgreaves.com \
    --to=david@dgreaves.com \
    --cc=Mario.Holbe@TU-Ilmenau.DE \
    --cc=jnelson-linux-raid@jamponi.net \
    --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).