[CentOS-virt] Slightly OT: FakeRaid or Software Raid

Grant McWilliams

grantmasterflash at gmail.com
Wed Dec 2 22:14:37 UTC 2009

On Wed, Dec 2, 2009 at 12:59 PM, Christopher G. Stach II <cgs at ldsys.net>wrote:

> ----- "Ben M." <centos at rivint.com> wrote:
> MD RAID. I'd even opt for MD RAID over a lot of hardware implementations.
> This writeup summarizes a bit of why:
> http://jeremy.zawodny.com/blog/archives/008696.html
> Hardware RAID's performance is obviously going to be better, but it's only
> worth it if you *need* it (more than ~8 disks, parity). If you're just doing
> RAID 0, 1, or 10 in a single box and you're not pushing it to its limits as
> a DB server or benchmarking and going over it with a magnifying glass, you
> probably won't notice a difference in performance.
> --
> Christopher G. Stach II
He had a two drive RAID 1 drives and at least one of them failed but he
didn't have any notification software set up to let him know that it had
failed. And since that's the case he didn't know if both drives had failed
or not. I wonder why he things software RAID would be a) more reliable b)
fix itself magically without telling him.  He never did say if he was able
to use the second disk. I have 75 machines with 3ware controllers and on the
very rare occasion that a controller fails you plug in another one and boot

I don't use software RAID in any sort of production environment unless it's
RAID 0 and I don't care about the data at all. I've also tested the speed
between Hardware and Software RAID 5 and no matter how many CPUs you throw
at it the hardware will win.  Even in the case when a 3ware RAID controller
only has one drive plugged in it will beat a single drive plugged into the
motherboard if applications are requesting dissimilar data. One stream from
an MD0 RAID 0 will be as fast as one stream from a Hardware RAID 0. Multiple
streams of dissimilar data will be much faster on the Hardware RAID
controller due to controller caching.

Grant McWilliams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20091202/b3889cf1/attachment-0002.html>

More information about the CentOS-virt mailing list