linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).