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 22:19:59 -0400 [thread overview]
Message-ID: <51D77ECF.5090909@turmel.org> (raw)
In-Reply-To: <1373073066.10569.30.camel@fermat.scientia.net>
On 07/05/2013 09:11 PM, Christoph Anton Mitterer wrote:
> On Fri, 2013-07-05 at 09:36 -0400, Phil Turmel wrote:
>> You picked "redundancy". Leaves only only one axis to consider: speed
>> vs. capacity.
> Well thinking about that "raid6check" tool you told me over in the other
> thread,...
> which AFAIU does what I was talking about, namely telling me which block
> is the correct one if I have bad blocks (and the disk itself can't tell)
> and not whole drive failures,.. where at least a two-block copy RAID10
> would not be able to...
> ...then I think RAID6 is THE solution for me, given resilience has the
> highest priority, as RAID10 with c/f/o=3 cannot do that.
I think you should read Neil's blog entry before you get too excited
about raid6check. You can only trust its decisions when you are
confident that the problems it finds are *only* due to silent read
errors. MD raid does not carry the per-block metadata needed to
distinguish silent read errors from incomplete writes or out-of-band
writes to member disks.
Hopefully, btrfs will fill this void (eventually).
http://neil.brown.name/blog/20100211050355
Phil
next prev parent reply other threads:[~2013-07-06 2:19 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
2013-07-06 1:11 ` Christoph Anton Mitterer
2013-07-06 2:19 ` Phil Turmel [this message]
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=51D77ECF.5090909@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.