Re: Raid requirement

Just a few addenda inline...

"Howard J. Rogers" wrote:
>
> Note that RAID 5's performance penalty is entirely on
> the write side of things: for reads, it's just as parallelized as RAID 0,
> and just as fast as a result.

I'm not sure I'd go this far... I believe RAID5 still has a small (~10% or less) read penalty built in, esp. with sequential reads, when compared to pure striping. I haven't tested this myself mind you... but I do remember seeing some benchmarks to this effect.  

> RAID 1 is mirroring. You write your document to drive C, and it gets
> automatically written to drive D as well. There's no performance gain here
> at all... purely data redundancy. If Drive C bites the dust, your document
> is safe and sound on drive D.

Also I believe there can be a performance gain w/mirroring in that if one disk is busy servicing a different request, the other half of the mirror can supply the information. In other words, 2 concurrent read requests for different data, both of which reside on the same mirrored pair. One half of the mirror services one request, the other half the 2nd request. This is over-simplified and hardware dependent, but possible at least in theory.  

One last problem w/RAID5 - the rebuild time after a failure. With today's huge disks (EMC is using 73 GB these days, and growing?), it can take a day or more to rebuild a failed disk in a RAID5 set on a busy system. During this time performance suffers (constantly having to calculate parity for reads and writes, while still trying to rebuild the failed disk with more reads and writes), and you're exposed to a 2nd failure in the RAID set for a somewhat uncomfortably long period of time. A 2nd failure before it has finished the rebuild means all data in the set is lost.

For these reasons I believe EMC (and probably others) no longer support RAID5 on large disks without a written agreement from the customer saying, in effect "this probably is a really bad idea."

Regards,
Sean Received on Fri Jul 12 2002 - 10:48:22 CDT