From: Nifty Fedora Mitch <niftyfedora@niftyegg.com>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: Why do I need 4 disks for a raid6?
Date: Mon, 23 Mar 2009 13:20:43 -0700 [thread overview]
Message-ID: <20090323202043.GA3841@compegg.wr.niftyegg.com> (raw)
In-Reply-To: <18882.54987.332211.49180@notabene.brown>
> On Tuesday March 17, goswin-v-b@web.de wrote:
> > Hi,
> >
> > I'm wondering why the kernel requires a raid6 to have at least 4
> > disks (of which at most 2 can be missing). Why not 3 disks?
I should think that this is the 'defination' of a raid6.
If you build a raid6 resource it should be raid6 and
as such be able to tolerate the loss of two disks
and all the other raid6 properties.
If you build a raidN with three disks that can tolerate the
loss of one disk it is not raid6 but raid5 and should be called
by the correct descriptive name.
The importance of this strictness surfaces in documentation.
Both to the system admin working on the system and also
documentation from the system admin to his management that
is comparing prices and matching features. i.e. "Bob's raid6
is 25% less costly than Fred's". Truth in advertising comes
to play.
Hidden in this thread is an interesting notion of migration from a
"lesser" raid to a more durable raid over time. It might make sense to
facilitate limited tools to this end. Even for those sites that wish to stage
the construction of a large raid install or to stagger the poweron hours
and date codes of drives on the common notion that batches of drives
fail together. Or perhaps a "raid6 ready" raid5 that gets populated with
the absent drive on the first statistical sniff of an error outside of
the norm. Or the arrival of warrenty expiration....
Such a "raidN ready" setup does confuse the notion of operational health
for any monitoring tool and is likely a very bad idea for that reason alone.
This 2001 URL is interesting in the comments about how unfortunate the
choice of the world "level" was.
http://www.pcguide.com/ref/hdd/perf/raid/levels/index.htm
also interesting is the coment about a vendor being sloppy
with the technical language.
--
T o m M i t c h e l l
Found me a new hat, now what?
next prev parent reply other threads:[~2009-03-23 20:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-17 19:12 Why do I need 4 disks for a raid6? Goswin von Brederlow
2009-03-18 3:41 ` david.geib
2009-03-18 9:50 ` Goswin von Brederlow
2009-03-18 18:12 ` david.geib
2009-03-18 12:18 ` Andre Noll
[not found] ` <49C0EA5F.9070901@vshift.com>
2009-03-18 12:35 ` Andre Noll
2009-03-18 14:08 ` Goswin von Brederlow
2009-03-18 14:26 ` Robin Hill
2009-03-18 18:48 ` Goswin von Brederlow
2009-04-01 16:08 ` H. Peter Anvin
2009-04-01 17:47 ` Andre Noll
2009-04-01 20:36 ` H. Peter Anvin
2009-04-01 18:07 ` Goswin von Brederlow
2009-04-01 19:05 ` H. Peter Anvin
2009-03-19 23:35 ` Neil Brown
2009-03-20 10:20 ` Goswin von Brederlow
2009-03-23 20:20 ` Nifty Fedora Mitch [this message]
2009-03-24 19:32 ` Goswin von Brederlow
2009-04-01 16:09 ` H. Peter Anvin
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=20090323202043.GA3841@compegg.wr.niftyegg.com \
--to=niftyfedora@niftyegg.com \
--cc=goswin-v-b@web.de \
--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).