linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).