From: Asdo <asdo@shiftmail.org>
To: "Michał Sawicz" <michal@sawicz.net>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: Swapping a disk without degrading an array
Date: Mon, 25 Jan 2010 15:51:27 +0100 [thread overview]
Message-ID: <4B5DAFEF.7090500@shiftmail.org> (raw)
In-Reply-To: <1264421475.30742.49.camel@test.apertos.eu>
Michał Sawicz wrote:
> ... I wanted to start a discussion whether this at all makes sense, what can
> be the use cases etc. ...
This appears just a great feature to me, you get my vote.
I also was thinking about something similar. This is probably the most
desirable feature request for MD for me right now.
Use cases could be:
- 1 - the obvious one: you are seeing some preliminary errors
(correctable read errors, or SMART errors) on the disk and you want to
replace it without making the array degraded & temporarily vulnerable.
- 2 - recoverying from a really bad array having multiple read errors in
different places in multiple disks (replacing one disk at a time with
the feature you suggest): consider that while filling each sector of the
the hot-spare the algorithm has 2 places where to read data from:
firstly it can try read from the drive being replaced, and then if that
one returns read errors it can get the information from parity.
Currently there is no other way to do this with this level of redundancy
AFAIK, at least not automatically and not with the array online.
Consider that if you have a bad array as described, doing a full scrub
would take the array down, i.e. the scrub would never successfully
finish, and the new drive could never be filled with data. While with
the feature you suggest, there is no scrub on the whole array: data is
taken only from the drive being replaced for all the sectors (that's the
only disk being scrubbed), except possibly for a few sectors being
defective on that disk, for which parity is used.
Thank you
Asdo
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-01-25 14:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-25 12:11 Swapping a disk without degrading an array Michał Sawicz
2010-01-25 12:25 ` Majed B.
2010-01-25 12:53 ` Mikael Abrahamsson
2010-01-25 14:44 ` Michał Sawicz
2010-01-25 14:51 ` Asdo [this message]
2010-01-25 17:40 ` Goswin von Brederlow
2010-01-29 11:19 ` Neil Brown
2010-01-29 15:35 ` Goswin von Brederlow
2010-01-31 15:34 ` Asdo
2010-01-31 16:33 ` Gabor Gombas
2010-01-31 17:32 ` Goswin von Brederlow
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=4B5DAFEF.7090500@shiftmail.org \
--to=asdo@shiftmail.org \
--cc=linux-raid@vger.kernel.org \
--cc=michal@sawicz.net \
/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).