Write-Back cache questions

The storage system will acknowledge writes once data has been received in its Write Cache and has also been mirrored to Write Cache on the peer Storage Processor (that is; the data resides in two different places, for redundancy). Or, if Write Cache is disabled, when the data has been written out to physical disk. This is the inherent behavior of the storage system, and does not require configuration (other than selecting if Write Cache is enabled or disabled).

There are quite possibly configuration options for caching within the host operating system; those would be independent from the storage system's functionality as outlined above.

Regards,
DGM

I am only able to get about 1800 write IOPS from our CX300 regardless of the number of drives and raid configuration of our LUNs. That seems low to me. Is my HBA the limiting factor?

The IOPs you achieve will depend on many factors, however the CX300 scales with drives so to achieve maximum IOPs capability, with small IO sizes, you need more drives.

If you are just looking to get the most IOPs then small read IO from cache will effectively hit a limit at what the host can achieve after you have the data loaded into cache e.g. read several MB of data and then keep re-reading it. On the other hand you get the same effect if you write a small file and then keep re-writing it. Other operations will enforce a disk hit, random reads for example and these will then be a combination of disk speed, array utilisation, and IO characteristics; sequential or random, small or large IO.

Typically though, if you're limited to a number of IOPs the most likely issue is concurrency. Especially if random access, to get the most IOPs you will need to get multiple threads accessing each raid group. In this scenario, you get all the drives working with great efficiency, and the array will scale. The single HBA wouldn't be limiting you unless your target queue depth is set low. Typically this would be set to 256 with a LUN queue depth of 32 or 64. There is some good reference information in the CLARiiON Best Practices Guide that I recommend you read.

As a reference point, in a file serverving type application environment with a 4:1 read to write ratio, 8KB random IO, full array should be able to achieve in excess of 11000 IOPs. With any level of sequential activity, that will rise. As I suggested, the array scales so with only a few disks servicing load, you need to ensure concurrency but will be limited by the disks themselves unless serviced entirely by cache.

Back to your operation, it appears to be a single thread operation but you're not specific on that. If single thread to write cache, small IO size, then 1800 IOPs fits with one LUN access if 8KB IO. This does indicate an average response time of 0.56ms. If you can muti-thread, 16 threads with the same profile to a single 4+1 R5 LUN can yield in excess of 5600 IOPs. Alternatively, if you can access two LUNs concurrently, single thread each, you should increase to 2800 IOPs.

To summarise then, concurrency is the best option to increase IOPs with small IO sizes, then adding disks by way of more LUNs in seperate raid groups will scale. With single threaded applications, sometimes a way to increase throughput is to use a volume manager to stripe data on the host so mutiple host buffers are then used to read/write that file system i.e. force multiple threads below the application level. I'm not sure if that could be applied to your configuration though and no guarantess it would work - may depend on IO sizes and volume management stripe options.