What is this info mean?

[RAMbo]

I'm especially interested in how many disc writes I saved.
Looking at the 98%, read caching is extremely good or bad.





Volume (C:)
2019-01-01 17:45:05
-------------------
Total Read 639.51MB
Cached Read 626.83MB (98.0%)
L2Storage Read 0 (0.0%)
L2Storage Write 0
Total Write (Req) 33.91GB
Total Write (L1/L2) 33.91GB / 0
Total Write (Disk) 33.79GB (99.6%)
Urgent/Normal 0 / 33.79GB
Deferred Blocks 1020 (0.0%)
Trimmed Blocks 18948
Prefetch Inactive
Free Cache (L1) 20.50GB
Free Cache (L2) 0
Cache Hit Rate 98.02%

[Jaga]

That 98% Cached Read is your hitrate, meaning that disk reads happened in the cache instead of the physical disk. It's an extremely good hitrate you should be very happy with. Your Trimmed Blocks are also very high, which is writes that *would* have happened on the disk, except Primocache found them to be redundant, and so they were skipped completely.

Good performance with your configuration.

[RAMbo]

So the trimmed blocks is data that never got written to SSD?
How big is a block? The blocksize I configured or is it some other measure?

[Jaga]

Blocks means Primocache block size, that you set when you created the cache task. And yes - they weren't written to disk, because they didn't need to be.

[Support]

Exact amount of write-data reduced is Total Write (Req) - Total Write (Disk). So in the above case it is about 122MB, 0.4% of requested write-data (100% - 99.6%). Please note that this calculation doesn't count "Deferred Blocks" which is stored in cache and hasn't been written to disks yet.

Regarding how PrimoCache reduces writes, please see
http://www.romexsoftware.com/en-us/prim ... -wear.html

PS. The statistics “Deferred Blocks" or "Trimmed Blocks" only indicates the number of blocks. It doesn't mean that the data amount is "block count" x "block size", because the amount of data stored in a block varies. A block contain at least 512 bytes, so the data amount ranges from "block count" x 512 to "block count" x "block size".

[Jaga]

That's a good point, and it helps to be able to work out the data amount with those stats. Thank you for the clarity Support.

Are we still under the assumption that trimmed blocks are redundant writes that get discarded? I see it a lot with multi-part FTP downloads that complete, get assembled and copied off to another volume, so that they never actually hit the drive the parts are on due to the long deferred write time. I do see that the article about reducing writes has info related to TRIM, but that was never in Primocache before, and I have always seen a high number of Trimmed Blocks on my FTP client (L1+L2 Task).

[Support]

Yes, your understanding on "Trimmed blocks" are completely correct. When files are deleted, related data in cache will not be written to disks by PrimoCache any more since these data become useless now.

[RAMbo]

Exact amount of write-data reduced is Total Write (Req) - Total Write (Disk). So in the above case it is about 122MB, 0.4% of requested write-data (100% - 99.6%).

So the write caching performance is very bad?

I'm going to post results of some tests tonight. Everything seems so conflicting.
One test I did was:
a] Reset cache, cache off, download 7.5GB from usenet. Total data written 15GB. That could be right because the 7.5GB is automatically unpacked using WinRAR.

b] Reset cache, cache on, same download. Total written 9.5GB.

[Support]

Reducing writes is only one effect of write caching. The most effect of write caching is to improve writing speed.
If you only focus on reducing writes, you may use a longer latency which is at least 30 seconds. The reduced ratio is also related to your data usage scenario. You can easily see that PrimoCache reduces writes mainly in following two ways: 1) Consolidates multiple writes on the same address, and 2) Trims deleted files. See http://www.romexsoftware.com/en-us/prim ... -wear.html
So if there's no files deleted, or few overwriting writes, you may not see much writes reduced.

[Jaga]

I've used a longer deferred write time before to enhance the Trimmed Blocks feature (300 or 600 seconds), but it really only shines with things like temporary files that are created, used, then deleted before the delay runs out. Plus - you really should have a UPS on the machine if you're going to use deferred writes. You can get away with not having one and using a short delay (like 5s), but there's still a small amount of risk if the machine BSODs.