Flash Pool allows you to cache both random reads and random writes. To fine tune read caching, you use the Flash Pool read caching policies, as discussed in the Flash Pool Read Policies blog. By the same token, if you want to fine tune the write caching, you use the Flash Pool’s write policies. There are two such policies, as described below.
write-cache = none. If this policy is set on a particular volume, no random writes to this volume will be placed on SSDs thereafter. This means effectively, write caching for this volume is disabled. All random writes will go to hard disk drive (HDD) as they would on a normal aggregate. If your workload does not do random overwrites frequently, then this policy should be a good fit.
write-cache = random-write. This policy will cause frequent random overwrites being written on SSDs rather than HDDs. This provides a new and fast destination for those overwrites, thus reducing the I/O load on HDDs. The data in the write cache could also satisfy host reads if they happen to be cache hits, thus further reducing the load on HDDs. This is the default policy, as it is a target use case of Flash Pool.
These policies look good on paper. But how do I know if my workload is doing random overwrites to the same block locations frequently? Often it is not obvious or trivial to pin point the exact I/O patterns. Therefore, it is not easy to choose the best write caching policy. What one could do then is to run a couple quick tests, with write-cache=none followed by write-cache=random-write; and then compare the results.
Note that both of the policies can be set on a per-volume basis. For example, you can set write-cache=none for volume1 and at the same time set write-cache=random-write for volume2.