[ale] Raid perf?

Jim Kinney jim.kinney at gmail.com
Fri Oct 24 21:04:52 EDT 2008


On Fri, Oct 24, 2008 at 6:22 PM, Greg Freemyer <greg.freemyer at gmail.com>wrote:

> Jeff,
>
> Raid 10 is slightly less redundant than Raid 6
>
> If I have a Raid 10 with 6 drives and one fails I end up with 5 good
> drives, but 1 of them is no longer redundant, so if it happened to
> fail you lose the whole thing.
>
> (Yes I'm talking about a dual disk failure where both disks happen to
> be partners of each other.)
>
> Raid 6 can function in dual drive failure, regardless of which 2 drives
> fail.
>
> FYI: Raid 10 with large numbers of disks can handle even more than 2
> failures if you don't lose any mirror pairs.  Raid 6 will always fail
> if you have a 3 disk failure.
>
> OTOH,
> Raid 10 has a 50% waste of drives.
>
> Raid 6 is only wasting 2 drives, so if you have 5 or more drives in
> your array it has less waste.
>
> The negative is the write speed.  To update a Raid 10, you just have
> to write your update to two places.  i.e 2 i/o's per write.
>
> With Raid 6, you apparently have to read the 3 drives worth of info to
> figure out the original parity state, then write all 3 of those drives
> with updated info.  Thus 6 i/o's for each write.
>
> Back in the dark-ages when hard drives were a kilo-buck and up, raid 5 made
sense. With 1TB drives under $200, wasting drives to make a raid10 does not
compare to wasting time/$$ restoring mission critical from backup. It is
possible to create a 3-way mirror and then stripe across that. Not in
hardware, mind you, but the tiny performance hit is justifiable against the
massive portability of Linux software raid. Just put the drives in a new box
and tell the bios which one has the boot partition.

There are some tweaks in hdparm that can make the drive flush write buffers
more often so the catastrophic mobo failure will be less likely to cause ral
data loss.

-- 
-- 
James P. Kinney III
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20081024/2c20a75f/attachment.html 


More information about the Ale mailing list