Now let’s see what we have at random writing.
The number of disks in the array and the total amount of cache memory makes the trick here. Take note of the nearly ideal scalability of performance depending on the number of disks. Note the shape of the graphs, too. This is actually an example of how they should look.
For the checksum-based arrays the number of disks is still important as is indicated by the results of the eight- and four-disk RAID5 arrays. However, the checksum calculations are a factor, too. This is the reason why the RAID6 (for which two rather than one checksum must be calculated) are slower than the RAID5.
The degraded RAID6 without two disks is terribly slow again. You should not let it degrade that much – it feels really better with only one failed disk.
The number of disks matters with large data blocks, too. A disk mirror must be viewed as a single disk here. The four-disk RAID0 has poor performance due to unexpected problems with large data blocks. The degraded RAID10 is impressively good: it is occasionally faster than the normal RAID10 of the same size!
It is the number of disks that’s important for the checksum-based arrays when processing large data chunks. There are no performance slumps here. All checksums are calculated at a high speed. The degraded arrays are good. They just do not “notice” that they lack one disk. The RAID6 without two disks is the only configuration to show poor performance, which is an obvious flaw in the controller’s firmware.