Free cache on written and write cache mode

[kagankaragulle]

Here is my setup. The problem is one of the cache tasks flush the L2 write cache near instatenously, but one always stays full. Is this a bug? Pressing flush does not work.

1.jpg (162.32 KiB) Viewed 3442 times

2.jpg (162.78 KiB) Viewed 3442 times

Any ideas why it happens?

[Support]

Thank you all for the detailed discussion on this point. Just some clarifications and confirmations here.
1. "Free Cache on Written" only applies to the defer-write option as you can see it is in the "Advanced Defer-Write Options" dialog. So if "defer-write" is not enabled, then this switch has no effect.
2. "Free Cache on Written" only applies to "dirty" cache blocks. "Dirty" cache blocks means these cache blocks have write-data that haven't been written to target disks.
3. If cache space is almost full of "dirty" blocks, "urgent write" will be triggered and some dirty blocks will be written to disk by force and then ready for caching new incoming data. This will affect normal block schedule. However, users shall adjust parameters (increase cache space or reduce latency etc.) to avoid "urgent write". So for simplicity, here we don't take "urgent write" into consideration.
4. As designed for better cache performance, cached data in blocks are always present for future reading back as long as these blocks are not asked for caching new data, whether you enable "Free Cache on Written" or not, and whatever caching strategy (read-only/write-only/read-write) you choose, or whether you have flushed "dirty" cache blocks to disks.
So usually in the end the whole cache space will be full of cached data. That's why you see "Free Cache (L1/L2)" in the statistics stays to almost 0 in the end. PrimoCache will overwrite old cached blocks to cache new data according to certain cache replacement algorithm.
5. An exception to #4, when a file is deleted and a trim command is issued, related cache blocks will be completely freed. So sometimes you see "Free Cache (L1/L2)" increases.
Here, PrimoCache hasn't implemented TRIM commands to L2 SSD, informing L2 SSDs that these blocks are not used any more. We're working on it.
In other cases of caching work, PrimoCache will not and shall not send TRIM commands to L2 SSD.
6. Generally PrimoCache picks up blocks for caching new data in the following order: fresh blocks > written blocks ("Free Cache on Written" is on) > cached blocks scheduled by replacement algorithm.
For L2 cache, it is more complicated because PrimoCache also prefer blocks that are in continuous address range, in order to get best read/write performance.
7. Come back to the "Free Cache on Written" option. This option was introduced in very early versions when PrimoCache didn't support individual read/write cache space. At that time, for a read-write cache strategy, cache space had to be shared for both reading and writing. The option was designed to reduce the affect to the read cache by writing.
8. If your most writing workload is to overwrite existing files, enabling "Free Cache on Written" can reduce the chance of writing fixed blocks to some extent. If your working scenario is writing a new file or appending a file, then PrimoCache's cache replacement algorithm has already been enough to equally use/recycle all L2 SSD blocks.
I hope these help.

[Jaga]

Great info, thank you Support.

[mell111]

Thank you also from me, Support. Can you just clarify why the TRIM implementation you're working on won't also be issued upon a "clear cache" or "reset cache" (are those two the same?) That also seems like a natural place for it in addition to file deletion.

[Support]

@mell111, oh, sorry, I was talking about the normal cache block schedule. For the "reset/clear cache" (they are same), we will also send TRIM commands.

[mell111]

Great. That will help a lot. Thanks!