Write Cache Efficiency Topic is solved

[Davey126]

Curious if anyone has seen the behavior shown below where 'Total Write (Done)' exceeds 'Total Write (Req)'. I manage PrimoCache on several different systems and typically see 20-40% write-through savings when write caching is enabled depending on parameters and work load/type. This is the only system that utilizes 'invisible memory' for L1 caching. I wonder if that is messing up the stats.

[Support]

Did you do "Reset Stat" before?

[Davey126]

I did reset the cache a couple times while tuning parameters after initial setup. Just did so again without changing anything else. Will report back in 12-24 hours. Would be wonderful if was that simple.

[Support]

Well, then it is possible. For eg. Windows issues 100MB write-data request, Total Write (Req) will increase 100MB. Because Defer-Write is enabled, these 100MB write-data will be written to the cache first and then written to the disk after certein delays. If you reset the statistic before cached data are written to the disk, Total Write (Req) will be 0. However, Total Write (Done) still will increase to 100MB after data are written to the disk. That's why you see Total Write (Done) > Total Write (Req).

[Davey126]

Thanks. However, the scenario outlined by support was not relevant to my situation. The reset was accomplished by stopping/starting the cache, often following a parameter change. This automatically synchronizes the cache contents and associated user friendly metrics. The method support referenced involves right clicking within the numerical statics (middle box) and selecting 'reset'. That only resets the display, not the cache contents.

Through further experimentation I have determined write cache 'efficiency' (my term) is dependent on SSD brand and cache block size. More testing is needed but the brand of SSD used by the machine in question clearly does not like 16KB block sizes. Most of my machines use drives with older sf-2281 controllers but obviously vendor firmware tuning is coming into play. All drives have the same reported capacity. I am playing around with 4KB and 8KB block sizes with smaller yielding higher efficiencies. This is not unexpected but the magnitude of differences clearly has a SSD brand (more accurately firmware) correlation.

More to come as data is collected.

[InquiringMind]

I'm seeing a similar issue (running on an SSD-RAID setup with 64KB blocks). Using larger (128KB rather than 64KB) blocks in PrimoCache does seem to slightly lessen the problem along with using the Native algorithm for cache writes. However the "Total Write (Done)" figure isn't divisible by block size so I do wonder if it may be inaccurate.

[Support]

Ok, this issue raises from the design level. Both Total Write (Req) and Total Write (Done) are accurate. The root cause is that read cache and write cache share one tracing bitmap in order to reduce overhead and overload. Total Write (Done) may be amplified because of reading. Using a smaller block size may have a little help. Using "Write-data Only" strategy can completely remove this issue if you don't need read cache.

Edit on Jul. 10: Sorry the strategy "Write-data Only" cannot solve this write amplification issue. It does not help much for this issue. Currently there's no workaround for this issue.

[InquiringMind]

Ok, this issue raises from the design level. Both Total Write (Req) and Total Write (Done) are accurate. The root cause is that read cache and write cache share one tracing bitmap in order to reduce overhead and overload.

In that case, doesn't it mean that the terms are improperly described? If the "Total Write (Done)" figure is affected by read activity, then it cannot accurately describe write activity.

Total Write (Done) may be amplified because of reading. Using a smaller block size may have a little help. Using "Write-data Only" strategy can completely remove this issue if you don't need read cache.

Tried this (had to restart my system since PrimoCache wouldn't cache the D: drive for some reason when changed) and still encountered the same issue - see screenshot.

[Davey126]

Ok, this issue raises from the design level. Both Total Write (Req) and Total Write (Done) are accurate. The root cause is that read cache and write cache share one tracing bitmap in order to reduce overhead and overload. Total Write (Done) may be amplified because of reading. Using a smaller block size may have a little help. Using "Write-data Only" strategy can completely remove this issue if you don't need read cache.

Thanks. Helps explain the somewhat inconsistent results I am seeing with variable block sizes. Smaller helps a little but not consistently. I am less comfortable with the Write-data Only suggestion as I still see amplification in this scenario. It seems to be worse when invisible memory is used which is when I first noticed the problem. We have a few 32-bit systems that can't be economically upgraded to 64-bit. Perhaps why I did not pick-up on this before as most builds are 64-bit.

Something isn't right; I don't think the common tracing bitmap fully explains it.

[Support]

My fault. The strategy "Write-data Only" cannot remove this write amplification issue. It helps a little but also not consistently. The root cause is the common tracing bitmap and I'm sorry that currently there's no workaround for this issue.