In case of RAID4 or RAID5, for each stripe of data bits, a parity bit is stored. For example if I write 0 to drive A and 1 to drive B, then parity bit 1 is stored to drive C. Isn't this a huge load to CPU in case of Linux software-RAID if for each bit of data, a parity bit needs to be calculated? For example if I write a 1GB file to RAID5 array, then 8000000000 XOR calculations needs to be performed by CPU?

  • 1
    RAID4 isn't used anymore unless you happen to be a particular storage vendor, and RAID5 isn't used anymore by people who care about their data. So use RAID6/0 or RAID 1/0. And think about your processor clock speed and what that actually means. – HopelessN00b Mar 11 '14 at 13:30
  • @HopelessN00b I see. But for example in case of SSD's, which support sequential write speeds >500MB/s, this would mean 4000000000 XOR calculations per second. Even for multi-core processors, this seems to be considerable load, isn't it? – Martin Mar 11 '14 at 13:59
  • @Martin a little naive. Really. See.... that is 4000000000 BYTES being XOR'ed, but since we run today on 64 bit processors registers are 8 bytes (in one operation). And XOR is about the easiest operation for a processor. Interesting enough you will spend more time loading and unloading the data. Also, SSD are the extreme example. Normally RAids will be DIscs and man, there you talk if you are lucky of 20 or 30 or 40 mb/second with random access. WAAAAYY less. If you spend for SSD, spend for a raid controller. – TomTom Mar 11 '14 at 14:11
  • @TomTom if you write a 1GB file at 0.5GB/s, then you have to perform 4G XOR operations in a second. However, I fully understand your point and SSD's in RAID5 is indeed an extreme example. – Martin Mar 11 '14 at 14:32
  • @Martin No, because 1 XOR operation can handle 8 bytes minimum. Also you can do multiple in parallel - moving the data in and out of the processor is the main issue as this type of operation trashes any caching on any level of the processor. The XOR operations will not be the main issue. – TomTom Mar 11 '14 at 15:26

As TomTom has said, it's not as brutal as it used to be; but then disc drives have got bigger while CPUs were getting faster.

Which is why it's not a good idea to do RAID-5 in software unless you really don't care about performance. RAID-5 in hardware at least ensures there's a reserved processor whose sole job is to do those parity calculations; also, the hardware will often have things like NVRAM to prevent array corruption, and the ability to optimise the calculations, eg by knowing that a whole stripe is being written and skipping the (hugely expensive) read-modify-write cycle in favour of a simple parity recalculation.

Even with hardware RAID acceleration, applications that modify very small chunks of data at a time - particularly databases - can perform very badly indeed on RAID-5 (and RAID-6, which is even more expensive in terms of parity calculation). For that kind of application, just put your hand in your pocket, get the extra discs, and do RAID-1+0.


You mean for a modern CPU with like 6-8 cores all many times more powerfull than that on a RAID card?

Not today, This is 2013. CPU's can handle a LOT of stuff these days. You will have problems using up the power of a single core, unless you run quite a lot of SSD's to RAID.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.