From: David Greaves <david@dgreaves.com>
To: Billy Crook <billycrook@gmail.com>
Cc: Justin Piszcz <jpiszcz@lucidpixels.com>,
Bill Davidsen <davidsen@tmr.com>, Neil Brown <neilb@suse.de>,
Linux RAID <linux-raid@vger.kernel.org>,
dean@arctic.org
Subject: non-degraded component replacement was Re: Distributed spares
Date: Tue, 14 Oct 2008 13:02:17 +0100 [thread overview]
Message-ID: <48F48A49.2000200@dgreaves.com> (raw)
In-Reply-To: <a43edf1b0810131530x36a69089la0d5d26a2228b796@mail.gmail.com>
Billy Crook wrote:
> It would be even nicer if there were a way to hot-transfer one
> raid component to another without setting anything faulty. I suppose
> you could make all the components of the real array be single disk
> raid1 arrays for that purpose. Then you could have one extra disk set
> aside for this sort of scrubbing, and never even be down one of your
> parities. I guess I should add that onto my todo list....
IMHO This one should be high on the todo list. Especially if it's a
pre-requisite for other improvements to resilience.
Right now, if a drive fails or shows signs of going bad then you get into a very
risky situation.
I'm sure most here know that the risk is because removing the failing drive and
installing a good one to re-sync puts you in a very vulnerable position; if
another drive fails (even one bad block) then you lose data.
The solution involves raid1 - but it needs a twist of raid5/6.
http://arctic.org/~dean/proactive-raid5-disk-replacement.txt
I think this is what was discussed:
Assume md0 has drives A B C D
D is failing
E is new
* add E as spare
* set E to mirror 'failing' drive D (with bitmap?)
* subsequent writes go to both D+E
* recover 99+% of data from D to E by simple mirroring
* any md0 or D->E read failures on D are recovered from reading ABC not E unless
E is in sync. D is not failed out. (and it's these tricks that stops users from
doing all this manually)
* any md0 sector read failure on ABC can still (hopefully) be read from D even
if not yet mirrored to E (also not possible
* once E is mirrored, D is removed and the job is done
Personally I think this feature is more important than the reshaping requests;
of course that's just one opinion :)
David
next prev parent reply other threads:[~2008-10-14 12:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-13 21:50 Distributed spares Bill Davidsen
2008-10-13 22:11 ` Justin Piszcz
2008-10-13 22:30 ` Billy Crook
2008-10-13 23:29 ` Keld Jørn Simonsen
2008-10-14 10:12 ` Martin K. Petersen
2008-10-14 13:06 ` Keld Jørn Simonsen
2008-10-14 13:20 ` David Lethe
2008-10-14 12:02 ` David Greaves [this message]
2008-10-14 13:18 ` non-degraded component replacement was " Billy Crook
2008-10-14 23:20 ` Bill Davidsen
2008-10-14 10:04 ` Neil Brown
2008-10-16 23:50 ` Bill Davidsen
2008-10-17 4:09 ` David Lethe
2008-10-17 13:46 ` Bill Davidsen
2008-10-20 1:11 ` Neil Brown
2008-10-17 13:09 ` Gabor Gombas
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=48F48A49.2000200@dgreaves.com \
--to=david@dgreaves.com \
--cc=billycrook@gmail.com \
--cc=davidsen@tmr.com \
--cc=dean@arctic.org \
--cc=jpiszcz@lucidpixels.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.