Questions about block size

[Support]

If you have enough RAM installed, it's ok. But I prefer to reduce memory overhead and add saved RAM to L1 cache.

[InquiringMind]

The "overhead" refers to the size of the index that has to be used to manage the cache. This index stores information like which (disk) block each cache block is taken from and speeds up the storage and retrieval of cached data. Having a large number of cache blocks means a larger index which requires more memory (hence the "overhead") and means that searches take longer.

Larger PrimoCache blocks mean a smaller index is needed (less overhead, faster searches) but does mean that some data may be cached unnecessarily. On the other hand, since a lot of data is accessed sequentially (large file reads), a large block size can act as "read ahead cacheing". In most cases a 4KB PrimoCache block size will be too small and a 16-64KB block size would offer better performance.

[Jaga]

If you have enough RAM installed, it's ok. But I prefer to reduce memory overhead and add saved RAM to L1 cache.

Agreed, especially since gaming was noted as an activity on the machine. The slight dip in performance is more than offset by recouping the extra RAM to give both Windows and games/processes the "breathing room" they need to run effectively.

[TomB]

The "overhead" refers to the size of the index that has to be used to manage the cache. This index stores information like which (disk) block each cache block is taken from and speeds up the storage and retrieval of cached data. Having a large number of cache blocks means a larger index which requires more memory (hence the "overhead") and means that searches take longer.

Larger PrimoCache blocks mean a smaller index is needed (less overhead, faster searches) but does mean that some data may be cached unnecessarily. On the other hand, since a lot of data is accessed sequentially (large file reads), a large block size can act as "read ahead cacheing". In most cases a 4KB PrimoCache block size will be too small and a 16-64KB block size would offer better performance.

Most (or much) of InquiringMind's post above seems intuitively likely to me.

However, can @Support or others comment on whether or not some of the statements above are in fact correct to the point that they would make a significant difference? (I'm particularly interested in the parts in bold.)

(I want to have most effective use of memory and so I wonder how best to allocate memory. I have 32GB on the machine and have approximately 10GB RAM available after OS, other basic programs and services, and all PrimoCache tasks are loaded. I am using a 180GB SSD as L2 cache for a 1TB HDD. Overhead is 3.5GB using 4k block sizes. I also have 3 L1 cache tasks for other drives, one with 8GB, one with 4GB and one with 1GB.)

Thanks in advance ...

Tom

[Jaga]

I'd recommend you try 32KB block sizes to start and see how that works for you. I use 16KB blocks caching a 1TB NVMe, but my system has 64GB of RAM. The overhead on my end is quite small by comparison.

As a side note: there's a sticky for discussing optimal setup for different uses over here. Might be a good place to take the discussion, and give it some reading as well.

[TomB]

Thank you, Jaga.

I'll try experimenting with a larger block size.

All of my drives have 4KB clusters, so I've been using 4k cache blocks mainly because of these and similar statements in the PrimoCache Manual and FAQ:

From the FAQ: "To get the best performance, a block size equal to or less than the cluster size of the volume file system is recommended. However, if you see that the memory overhead is too large with such block size, you may try a bigger block size."

From the manual: "Block Size: Cache is logically partitioned into blocks of fixed size, typically ranging from 4KB to 512KB. Cache block is the smallest unit that PrimoCache manages. A smaller block size brings more available blocks for the same amount of cache space and usually higher performance. However, it will need larger memory overhead and may cause heavy CPU overload. To reach the best performance, a value equal to or less than the cluster size of the file system is recommended."

[Jaga]

The theory behind using the smallest block size in a Primocache Cache Task to achieve the best performance is in fact true. However, there are trade offs by doing so: higher RAM overhead tracking the cache blocks, and increased CPU use managing them. If your system runs apps that have low CPU overhead and you have far more RAM than they need (i.e. 64 or 128+ GB), then it's clear to use 4KB blocks. Most systems however don't have that luxury, and need to use larger block sizes to compensate by lowering CPU and RAM use. Even with my 64GB RAM system (and 8 logical processors) I chose to use 16KB blocks instead of 8k or 4k, particularly because the underlying drive is a Samsung NVMe where fast read/write performance can help offset the extra caching activity. I don't see much difference on my end by using a block size that is 4x the smallest, but I do get back CPU cycles and RAM.

You'll have to play with the block size and see what works for you the best. I'd recommend no smaller than 8k blocks, but no larger than 32k. Somewhere in there is going to be your sweet spot - I'm guessing based off prior experience that either 32k or 16k will be optimal for you, but you won't know until you test and see.

[InquiringMind]

From the FAQ: "To get the best performance, a block size equal to or less than the cluster size of the volume file system is recommended. However, if you see that the memory overhead is too large with such block size, you may try a bigger block size."

That entry should really be changed - there is absolutely no benefit in using a smaller block size that the current NTFS cluster size and it would result in higher memory overheads for the index. It really should state "a block size equal to or greater than the cluster size...".

[Support]

Because the discussion is off the previous topic, I split posts and made a new topic here.

[Support]

That entry should really be changed - there is absolutely no benefit in using a smaller block size that the current NTFS cluster size and it would result in higher memory overheads for the index. It really should state "a block size equal to or greater than the cluster size...".

Because of the program implementation, when the cache block size equal to or smaller than the target volume's cluster size, the performance of the sequential read/write will be the best. You are right, a smaller block size than cluster size is no benefit. So it should be "a block size equal to the cluster size".