![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Shall i tell you a little secret? 
It is common belief that RAID5 is heavy on your CPU 'because it needs to calculate the parity'. However, the truth is much different, and even an Atom can do more than 2GB/s of XOR parity calculations; XOR is about the easiest instruction you can give your CPU, it's only limited by memory bandwidth. Some high-end systems can do more than 100GB/s of XOR calculations.
So when doing RAID5 or RAID6 the XOR is only a few percent of the total CPU usage by the RAID5 driver. So what is cpu intensive then? Answer: the splitting and combining of requests, to make the requests of the right size. This is especially true for traditional RAID5 with 'writeback'; it will hold a buffer of incoming write requests. It will try to glue them together, and form a 'full stripe block' of about a megabyte; only this magical size can be written to disk without letting the disks seek; so RAID5 writing is ALWAYS slow, except when writing exactly that magical value.
Some RAID5 engines have no such intelligence, and as such as extremely slow when writing, these can still be fast if you write requests of a particular size. Intelligent RAID5 drivers do this themselves and maintains writeback so it can scan for incoming write requests, glue them together and write in the most optimal write size; there is only one size which is fast.
RAID5 can only write fast when:
disk1: stripe 128K
disk2: stripe 128K
disk3 stripe 128K
disk4 stripe 128K
In this case the full stripe block is (4-1) * 128K = 384KiB. So only this size will be fast, and most of the CPU usage by the driver will be to make this 'write request split&combine' possible.
If you are going to use compression, encryption, de-duplication you would want more cores, but a fast dualcore like E8400 should be enough for a 8/16GiB ZFS system really; ZFS is much more memory hungry than CPU hungry. These CPUs are also 45nm and thus very power efficient.
It is common belief that RAID5 is heavy on your CPU 'because it needs to calculate the parity'. However, the truth is much different, and even an Atom can do more than 2GB/s of XOR parity calculations; XOR is about the easiest instruction you can give your CPU, it's only limited by memory bandwidth. Some high-end systems can do more than 100GB/s of XOR calculations.
So when doing RAID5 or RAID6 the XOR is only a few percent of the total CPU usage by the RAID5 driver. So what is cpu intensive then? Answer: the splitting and combining of requests, to make the requests of the right size. This is especially true for traditional RAID5 with 'writeback'; it will hold a buffer of incoming write requests. It will try to glue them together, and form a 'full stripe block' of about a megabyte; only this magical size can be written to disk without letting the disks seek; so RAID5 writing is ALWAYS slow, except when writing exactly that magical value.
Some RAID5 engines have no such intelligence, and as such as extremely slow when writing, these can still be fast if you write requests of a particular size. Intelligent RAID5 drivers do this themselves and maintains writeback so it can scan for incoming write requests, glue them together and write in the most optimal write size; there is only one size which is fast.
RAID5 can only write fast when:
disk1: stripe 128K
disk2: stripe 128K
disk3 stripe 128K
disk4 stripe 128K
In this case the full stripe block is (4-1) * 128K = 384KiB. So only this size will be fast, and most of the CPU usage by the driver will be to make this 'write request split&combine' possible.
If you are going to use compression, encryption, de-duplication you would want more cores, but a fast dualcore like E8400 should be enough for a 8/16GiB ZFS system really; ZFS is much more memory hungry than CPU hungry. These CPUs are also 45nm and thus very power efficient.
