From: Phil Turmel <philip@turmel.org>
To: Christoph Anton Mitterer <calestyo@scientia.net>
Cc: linux-raid@vger.kernel.org
Subject: Re: question about the best suited RAID level/layout
Date: Fri, 05 Jul 2013 09:36:57 -0400 [thread overview]
Message-ID: <51D6CBF9.2020100@turmel.org> (raw)
In-Reply-To: <1372978687.5249.52.camel@fermat.scientia.net>
On 07/04/2013 06:58 PM, Christoph Anton Mitterer wrote:
> Hi Phil.
>
> On Thu, 2013-07-04 at 17:43 -0400, Phil Turmel wrote:
>>> The focus is absolutely on data security/resilience,... and not at all
>>> on performance.
>> This particular statement trumps all other considerations.
> Sarcasm? (*Sheldon Cooper hat on*)
No sarcasm. Speed, redundancy, capacity. Pick two. Any gain in one of
those criteria must reduce one or both of the others. (Not really
binary on each, but you get the idea.)
You picked "redundancy". Leaves only only one axis to consider: speed
vs. capacity.
>> Triple-copy raid10
>> across four drives can match that resiliency, with dramatically better
>> performance, but with a substantial cost in capacity.
> hmm I've briefly thought about that as well (just forgot to mention
> it)... for some reason (probably a non-reason) I've always had a bad
> feeling with respect to that uneven mixing (i.e. three copies on four
> disks), AFAIU that would look like (each same number being the same
> chunck:
> +---------+ +---------+ +---------+ +---------+
> | sda | | sdb | | sdc | | sdd |
> +---------+ +---------+ +---------+ +---------+
> 0 1 2 0 1 3 0 2 3 1 2 3
> 4 5 6 4 5 7 4 6 7 5 6 7
> 8 9 10 8 9 11 8 10 11 9 10 11
Precisely. This is "raid10,near3". You can look up the "offset" and
"far" variants.
> And that gives me again, any 2 disks... but so much better performance?
Dramatically.
> With 4x 4TiB disks,.. RAID6 would give me 16/2 TiB... and the above
> would give me 16/3 TiB?!
> Quite a loss...
Yup.
> And AFAIU it doesn't give me any better resilience than RAID6 (by tricks
> like probabilities or so)?
At four drives, no. Any two. With five, there are some combinations of
three missing drives that'll still run.
> Can it be grown? Like when I want to use the 5th bay? What would it be
> then, still any 2 out of 5?
No.
>> Two-failure resilience is vital to completing recovery after replacing a
>> failed drive, particularly when the read error rates of consumer-grade
>> drives are involved.
> Well,... I have enterprise disks, and I have backups on different
> media,... but nevertheless,... I wouldn't "risk" RAID5 for my precious
> data
IMHO, enterprise drives and a good backup regime makes raid5 a
reasonable choice. Raid gives you uninterrupted *uptime* in the face of
hardware failure, and only hardware failure. But David already covered
that.
>> In your specific case, raid6 has one additional advantage: making future
>> expansion to the fifth bay a reliable, simple, no downtime event.
> Ah... so I couldn't online/offline grow a RAID10 with n/f/o=3 ?
No.
>> In your situation, I would use raid6. To mitigate the performance hit
>> on occasional random-access work, I would use a small chunk size (I use
>> 16k). That will somewhat hurt peak linear performance, but even
>> bluray-equivalent media streams only amount to 5 MB/s or so. That would
>> be 80 IOPS per device in such a four-drive raid6.
> I think RAID6 will be what I go for, at least unless the RAID10 with
> three blocks gives me any resilience bonus, which I can't see right now.
>
> Any ideas about the layout? i.e. left-symmetric-6, right-symmetric-6,
> left-asymmetric-6, right-asymmetric-6, and parity-first-6 ?
Certainly not any of the "-6" suffixes. Those isolate Q on the last
disk, hurting streaming performance, and setting up the possibility of
uneven performance when degraded. The default left-symmetric gives the
best chunk distribution for general use.
Phil
next prev parent reply other threads:[~2013-07-05 13:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-04 18:17 question about the best suited RAID level/layout Christoph Anton Mitterer
2013-07-04 21:43 ` Phil Turmel
2013-07-04 22:58 ` Christoph Anton Mitterer
2013-07-05 1:07 ` Brad Campbell
2013-07-06 0:36 ` Christoph Anton Mitterer
2013-07-06 5:29 ` Brad Campbell
2013-07-06 14:49 ` Christoph Anton Mitterer
2013-07-07 6:36 ` Brad Campbell
2013-07-06 7:40 ` Piergiorgio Sartor
2013-07-06 14:52 ` Christoph Anton Mitterer
2013-07-05 1:12 ` Stan Hoeppner
2013-07-06 0:46 ` Christoph Anton Mitterer
2013-07-06 8:36 ` Stan Hoeppner
2013-07-06 15:04 ` Christoph Anton Mitterer
2013-07-06 15:41 ` Matt Garman
2013-07-07 14:08 ` David Brown
2013-07-07 16:45 ` Stan Hoeppner
2013-07-07 17:26 ` Christoph Anton Mitterer
2013-07-09 15:50 ` Stan Hoeppner
2013-07-05 13:36 ` Phil Turmel [this message]
2013-07-06 1:11 ` Christoph Anton Mitterer
2013-07-06 2:19 ` Phil Turmel
2013-07-06 17:55 ` Christoph Anton Mitterer
2013-07-07 12:46 ` Bernd Schubert
2013-07-07 17:39 ` Christoph Anton Mitterer
2013-07-05 11:10 ` David Brown
2013-07-06 0:55 ` Christoph Anton Mitterer
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=51D6CBF9.2020100@turmel.org \
--to=philip@turmel.org \
--cc=calestyo@scientia.net \
--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).