From: Christopher Smith <csmith@nighthawkrad.net>
To: gsslist+linuxraid@anthropohedron.net
Cc: linux-raid@vger.kernel.org
Subject: Re: Best way to achieve large, expandable, cheap storage?
Date: Fri, 21 Oct 2005 14:42:12 +1000 [thread overview]
Message-ID: <435871A4.8040304@nighthawkrad.net> (raw)
In-Reply-To: <20051020111943.GA9757@anthropohedron.net>
Gregory Seidman wrote:
> You should at least read the following before using RAID5. You can agree or
> disagree, but you should take the arguments into account:
>
> http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt
This bloke makes some good points about the various downsides of RAID5
(which everyone involved in actually implementing production RAID
systems should already know), but IMHO he also makes some poor
assumptions and specious claims.
For example, his article suggests that "partial media failure" is a
problem that would only affect RAID5, when really it would negatively
impact any RAID system (your newly-synced mirror isn't much good if half
the data that just got mirrored to it was corrupted, nor is the speed
boost from RAID0 very helpful if half the data is corrupted). I'm also
not sure about his claims of RAID3 & 4 "always" checking parity - that
sounds like a vendor-specific implementation (and while I'm not a
developer, I fail to see why a RAID5 implementation couldn't be made to
do the same).
As another example, I'm 99% sure that SCSI drives *do* inform the OS
when they remap a bad sector and that any remotely modern IDE drive also
does sector remapping.
He also focuses solely on the worst-case scenario as a reason for
avoiding RAID5 completely. Certainly you have to take that into
account, but it's rather unfair to draw a general conclusion based only
on how a particular scenario might happen.
Added to that, he completely discounts a few things:
1. Where it's "handy" to keep lots of data easily available, but its
entire loss is not catastrophic - ie: data volume is more important than
redundancy (my workplace has such a requirement, although we use RAID6 -
but RAID6 suffers most of the same "problems" he's talking about)
2. Where cost is a significant factor. Certainly for a business, the
cost of going RAID10 over RAID5, when taking into account possible
losses, is probably not large. However, in a "home user" scenario,
where cost is almost always the deciding factor and performance is not
particularly important, going RAID10 over RAID5 is difficult to justify.
Similarly, if large amounts of data (10s of terabytes) is being
stored, the additional cost of RAID10 can become substantial.
3. You could potentially need a _lot_ more physical space to get the
same amount of logical storage in a RAID10 vs a RAID5, with associated
powering, cooling and logistical issues.
In short, RAID5 has its place. It's certainly not the
only-an-idiot-would-use-it train wreck that page makes it out to be.
CS
next prev parent reply other threads:[~2005-10-21 4:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-30 13:20 Best way to achieve large, expandable, cheap storage? Robin Bowes
2005-09-30 13:29 ` Robin Bowes
2005-09-30 18:28 ` Brad Dameron
2005-09-30 19:20 ` Dan Stromberg
2005-09-30 18:16 ` Gregory Seidman
2005-09-30 18:34 ` Andy Smith
2005-10-02 4:36 ` Christopher Smith
2005-10-02 7:09 ` Tyler
2005-10-03 3:19 ` Christopher Smith
2005-10-03 16:33 ` Sebastian Kuzminsky
2005-10-04 4:09 ` Christopher Smith
2005-10-20 10:23 ` Robin Bowes
2005-10-20 11:19 ` Gregory Seidman
2005-10-20 11:41 ` Robin Bowes
2005-10-21 4:42 ` Christopher Smith [this message]
2005-10-21 16:48 ` Gil
2005-10-21 20:08 ` Robin Bowes
2005-10-21 4:40 ` Christopher Smith
-- strict thread matches above, loose matches on Subject: below --
2005-10-27 19:12 Andrew Burgess
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=435871A4.8040304@nighthawkrad.net \
--to=csmith@nighthawkrad.net \
--cc=gsslist+linuxraid@anthropohedron.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).