From: David Brown <david.brown@hesbynett.no>
To: linux-raid@vger.kernel.org
Subject: Re: RAID 5 - One drive dropped while replacing another
Date: Wed, 02 Feb 2011 22:22:55 +0100 [thread overview]
Message-ID: <iichvf$ebq$1@dough.gmane.org> (raw)
In-Reply-To: <AANLkTinvurdEuDFcXycrf=5qoZwEjxSc2izf8e0dgQAq@mail.gmail.com>
On 02/02/11 17:48, hansbkk@gmail.com wrote:
> On Wed, Feb 2, 2011 at 11:24 PM, David Brown<david@westcontrol.com> wrote:
>> Of course, there is a cost - if you have 15 2TB drives, with one being a
>> warm spare shared amongst the raid1 pairs, you have only 6 x 2TB storage.
>
> Please correct me if I got the math (or anything else) wrong.
>
> If one didn't implement RAID5 (rather just using RAID0 or LVM) over
> the RAID1s, and were OK with the 6x2TB usable space out of 15 drives,
> then you'd have three spares (actually hot spares right?), allowing
> for *any four* drives to fail (but still as long as it wasn't a
> matched pair within the _much shorter_ rebuild time window.)
>
Your maths is okay - it's your understanding of failures that is wrong :-)
If you use raid0 over your raid1 pairs, and you lose both halves of a
raid1 pair, you data is gone. You can have a dozen hot spares if you
want, it still doesn't matter.
The point of having multiple redundancy is to handle multiple failures
at the same time, or while doing a rebuild. Hot spares are there so
that a rebuild can start automatically without someone feeding a new
drive in the machine, thus minimising your risk window. But they don't
improve the redundancy themselves.
The /really/ good thing about a hot spare is that the administrator
doesn't have to remove the faulty disk until the array is rebuilt, and
safely redundant again. That way there is no disaster when he removes
the wrong disk...
> While a RAID6+spare, where any three can fail (and unlike the above
> any two can fail within the (admittedly longer) rebuild window, gives
> *double* the usable space - 12x2TB.
Again, you are incorrect about the number of drives that can fail.
RAID6 + spare means any /two/ drives can fail. You are correct about
having a lot more usable space, but you have lower redundancy and a lot
longer rebuild times.
prev parent reply other threads:[~2011-02-02 21:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AANLkTinXTYds442gPrs9a9vKtWTo4OcDHDEzvO0njvyv@mail.gmail.com>
2011-02-01 23:27 ` RAID 5 - One drive dropped while replacing another Bryan Wintermute
2011-02-01 23:36 ` Roman Mamedov
2011-02-02 6:20 ` Leslie Rhorer
2011-02-02 14:21 ` hansbkk
2011-02-02 14:28 ` Roman Mamedov
2011-02-02 15:28 ` hansbkk
[not found] ` <AANLkTikm5unULgkUBM__d8N9XPReu9BtjijAHt9zzvaP@mail.gmail.com>
2011-02-02 16:29 ` hansbkk
2011-02-02 21:15 ` David Brown
2011-02-02 17:25 ` Leslie Rhorer
2011-02-02 17:51 ` hansbkk
2011-02-02 20:56 ` Leslie Rhorer
2011-02-02 14:29 ` Mathias Burén
2011-02-02 14:47 ` Robin Hill
2011-02-02 16:24 ` David Brown
2011-02-02 16:48 ` hansbkk
2011-02-02 21:22 ` David Brown [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='iichvf$ebq$1@dough.gmane.org' \
--to=david.brown@hesbynett.no \
--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 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).