SW-RAID 5 - how much CPU time and performance can it take?

Question

I have Debian squeeze 6.0.4, 4x WD RE4 500Gb 7200RPM, Athlon II X4 600E and 24GB RAM DDR3.

Since I work with SW raid 5, it takes much more CPU, than I think is enough.

How can I get know, how much CPU performance and CPU time my Software RAID 5 takes?

Do you think is there so big difference in performance between Phenom II X4 905e with L3 cache and Athlon II X4 600e without L3?

Do you think it will consume more CPU time, when using more different disks instead of same type, mark and series?

Is there difference between Raid 5 with 4 same disks from WD instead of RAID 5 with 4 different disks from hitachi, WD, samsung and seagate? True is, that 4 different disks could be maybe slower, than 4 same disks, but maybe more secure.

(we are speaking about Software linux raid on debian squeeze) Thank you

Answer 1

In terms of computing needs it is almost the same Raid 4 and 5 don`t make much difference. Raid 4 has drawbacks, if you use a "normal" disk for the parity disk. It might be better to use a faster, more robust drive there (NVRAM would be great).

But since we are talking about normal stock PC-hardware - stick to RAID5.

There the load is evenly distributed across all disks - they should be the same speed (with respect to read and write throughput to the disk).

If you can get 4 different manufacturers with the same characteristics this is not slower than 4 same drives. But is is not "more safe". More safe would be using RAID 10 with one halve of the drives from a different manufacturer than the other halve.

Practically only the manufacturing date matters. Drives from the same date tend to fail on the same date - but with just 4 disks odds are on your side here.

More critical would be a raid5 with 20+ same drives of the same manufacturing date...

About performance: IMHO every current multicore CPU should have enough power to do a little bit of parity computing. L3 cache does not matter here - the parity has to be computed on every write/read access - which is normally not the same on two sequential read/write-requests.

Your disk-controller might be the bottleneck in your setup (SATA II, I guess).