The workload of 16 requests makes things look the right way in case of RAID 5 array. The graphs now behave as they should (the performance drops a while down with every new step along the X axis for all arrays and doesn’t depend anymore on the number of HDDs in an array). And the array of four drives is faster than the one of three. RAID 1, RAID 10 and RAID 0 of four drives suffered a pretty interesting performance drop when the writes reached 10% of the entire requests share. Here Intel SRCS14L controller starts using lazy writing algorithms, since the write requests start appearing, but they are still too few to make the caching efficient. As a result, the whole thing slows down because of this caching. However, as soon as the share of writes reaches 20%, the contribution of the lazy writing to the overall performance improvement is indisputable.

Under the workload of 256 requests the performance drop in case of 10% writes becomes even bigger for the reasons mentioned above. The most interesting thing here is probably the RandomRead. Since the performance of 2-HDD RAID 1 is almost the same as that of a single drive at that point, Intel SRCS14L controller doesn’t use any technology similar to Twinstor from 3Ware. On the other hand, if we compare the performance of two-drive RAID 0 and RAID 1 arrays, we will see that the latter is almost as fast as the former (but not in case of 0% and 10% writes, as these are the errors of the controller algorithms sending requests to the drives of the array). In other words, Intel’s alternating technology does work, but is not stable enough.

The graphs for RAID 0 array look almost the same as the graph for a single HDD (of course, we also take into account the adjustment coefficient depending on the number of the HDDs involved), which means that the controller copes with this workmode perfectly well. The graphs for RAID 5 array are also close to being impeccable.

Now let’s consider the RAID 0 array of four drives and see how the disabled lazy writing will affect the performance.

As you can see, this influence is pretty high in case of small queues and drops down to naught as the queue depth increases. However, this influence is anyway highly positive. So, why not leave the lazy writing enabled by default? Because this way if the power goes down for some emergency reasons, everything stored in the buffer will be lost. Well, is higher performance worth sacrificing the reliability? Anyway, it is always great to have a choice: high speed or high data security, trick or treat… :)