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: Thu, 04 Jul 2013 17:43:38 -0400 [thread overview]
Message-ID: <51D5EC8A.40509@turmel.org> (raw)
In-Reply-To: <1372961877.8716.43.camel@heisenberg.scientia.net>
On 07/04/2013 02:17 PM, Christoph Anton Mitterer wrote:
> Hi.
>
> I'm setting up a 5-bay NAS (based on a QNAP device), with my personal
> Debian on it, currently using only 4 devices though
> The focus is absolutely on data security/resilience,... and not at all
> on performance.
This particular statement trumps all other considerations.
> Now questions comes, which RAID level to use, and I guess with the main
> focus on resilience there's only basically these options:
[snip /]
You covered all the basics.
From your own analysis, raid6 is the option that maximizes total storage
while achieving an "any two failures" resiliency. Triple-copy raid10
across four drives can match that resiliency, with dramatically better
performance, but with a substantial cost in capacity.
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.
In your specific case, raid6 has one additional advantage: making future
expansion to the fifth bay a reliable, simple, no downtime event.
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.
Phil
next prev parent reply other threads:[~2013-07-04 21:43 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 [this message]
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
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=51D5EC8A.40509@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 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.