Monday, June 27, 2016

Measuring IOPS part 3: of the impact of disk array cache on the results of DISKSPD

In the previous post we have welcomed the new kid on the block, namedly DISKSPD, and found out that, though it should disable hardware caching, the –h switch seems to have no effect on the HP SmartArray RAID controller cache. If we have a look at the SmartArray RAID performance factors document edited by HP, we can read that the Read Cache is useful in prefetching sequential reads:

Concerning the Write Cache, HP states that it is used to cheat on the host application by making it believe that the data have been written when they are not, and that if the Cache fills up, the Disk controller has some mechanisms to speed up execution, such as grouping logical blocks (write coalescing) or change the execution order to lower latency (command reordering):

So, the fact of using the HP SmartArray controller cache justifies the fact that, during my tests with Diskspd, I cannot see the write penalty which is typical for RAID 1 configurations:

To confirm the fact that the HP Controller is not honoring the request to disable caching, I can run Diskspd with the the –S switch (instead of -h). The –S switch disable the OS cache only. Since the result of this run and of the previous run are roughly the same, we can state that Diskspd can’t disable the SmartArray cache, only the OS cache:

This particular case apart, DISKSPD seems to be a nice tool by Microsoft. Let's keep studying it in the next post of this series (to be published).

1 comment:

  1. Great posts - thank you.
    Try same tests while using a diskspd data file larger than the controller cache size


Related Posts Plugin for WordPress, Blogger...