CSV4 is backed by a slow spinning array and has a 5GB L1 write-back cache. Our workload for CSV4 consists of bursts of 1-2 GB of sequential writes every 15-30 minutes and mostly sequential reads of 1-4GB at random times, with 25-50% of those reads from the last 5GB written. Based on performance, it appears that all writes to CSV4 are done at the underlying array's speed (slow), as if the cache were full or in write-through mode. In the Starwind console, the cache "Usage" figure for this image (and all CSVs) always shows 100%. I'm wondering if the cache is never being flushed, or if it's being flushed, the memory is never marked as free for future writes and it's only flushing when necessary. It looks like it's configured to flush after 5 seconds. I checked the Starwind service logs, but didn't see any problems related to caching. I've not yet tested whether the other CSVs are also performing as if in write-through mode.
My questions are:
- Is this a known issue or might we be doing something wrong? I'm happy to pm a Starwind log collector zip if this requires investigation.
- What are the criteria for the lazy cache writer to flush?
- When write-back caching is working correctly, how are flushing writes prioritized relative to reads when the cache is not full?
- Example: If I have a free 5GB cache, write 2GB to it, which is almost immediately acked to the client, and then try to read non-cached data while the 2GB is still flushing to my slow array, will VSAN prioritize my read?
- Will it pause the flush while disk activity is high?
- How does it prioritize flushing when the cache is full?
