Flushing cache to disk

[mell111]

I have a few questions about cache flushing:

With both L1 & L2 configured (for the same underlying disk) with Defer-Write, how is the flushing of the L1 and L2 cache coordinated at the latency interval to avoid a simultaneous write for both?

Also, in the case where, say, the L1 cache flush happens to be slow due to disk thrashing, will the L2 flush wait until the L1 flush completes (and vice versa)? How does the expiration of additional latency intervals before a flush completes affect this?

I'm referring to situation in which the slowness of the flush is temporary, but may last several latency intervals. I realize that after a long enough period the cache will fill up and throttle the writing altogether.

How would configuring L1 to flush to L2 when L1 fills affect the above scenario (as long as space is available, of course) ?

Finally, with a 256K block size in PrimoCache and Windows writing 4K blocks of data, will PrimoCache first fill its larger block before flushing (assuming incoming data from Windows continues)? Any additional insight into how the "mismatch" in block sizes between the disk, L1 and L2, would be welcome.

Thanks!

[Support]

With both L1 & L2 configured (for the same underlying disk) with Defer-Write, how is the flushing of the L1 and L2 cache coordinated at the latency interval to avoid a simultaneous write for both?

Also, in the case where, say, the L1 cache flush happens to be slow due to disk thrashing, will the L2 flush wait until the L1 flush completes (and vice versa)? How does the expiration of additional latency intervals before a flush completes affect this?

There is no single L1 flush or L2 flush. During regular flush (interval expired), all data in L1 and L2 will be flushed to disk. Program has been designed to ensure there will have no conflicts.

When both L1 and L2 are used in Defer-Write, it's recommended to enable the option " Flush L1 to L2" in the advanced defer-write options dialog. This option will been enabled by default in future versions.

For tuning Defer-Write parameters, please check https://www.romexsoftware.com/en-us/pri ... write.html

Finally, with a 256K block size in PrimoCache and Windows writing 4K blocks of data, will PrimoCache first fill its larger block before flushing (assuming incoming data from Windows continues)?

No, only 4KB data will be written to disk.

[mell111]

Thanks for clarifying.

Re. the 256K block size, would you kindly briefly explain where it comes into play and the advantages of a bigger or smaller block size. I saw in the documentation that a smaller block size would cause PrimoCache to use more memory, so setting that aside, what is the effect otherwise?

[Support]

Cache is logically partitioned into blocks of fixed size. Each cache block stores contiguous address sector data of corresponding size. When all cache blocks are used and new data needs to be cached, PrimoCache replaces the entire block and all cached data in this block will be cleared.

So a smaller block size brings more available blocks for the same amount of cache space and usually higher cache performance. However, it will need larger memory overhead and may cause heavy CPU overload.

[mell111]

You say: "Each cache block stores contiguous address sector data of corresponding size."

Can you clarify what you mean by "corresponding size" with a simple example?

By default for large disks, Windows will format NTFS with 4k block size. So if I understand you correctly, when Windows writes, say, 10 contiguous 4k sectors, they will be stored in one 256k (default) PrimoCache block and the next set of Windows 10 contiguous 4k sectors that are not contiguous with the first set will be stored in another PrimoCache 256k, etc. I'm not sure where "corresponding size" comes in.

If I understood correctly, I can see how larger block size would lead to fragmentation of the cache and reduced cache efficiency, with the advantages being reduced memory overhead and reduced CPU load.

I wonder, with this in mind, how such fragmentation affects PrimoCache management of the L2 cache (with Defer-Write), given that PrimoCache doesn't issue TRIM to the SSD. I saw in another thread that you mentioned that PrimoCache attempts to align to SSD erase bocks and I wonder if the fragmentation with a large block size interferes with that.

Of course, all of this assumes I even understood you correctly.

[Support]

Can you clarify what you mean by "corresponding size" with a simple example?

Sorry, I didn't express clearly. For eg. Assume the cache block size is 256KB, you can imagine that the disk storage space is also logically divided into 256KB space blocks linearly. A cache block will corresponds to one disk space block and caches data within this disk space block.