Block Size Implications

[mell111]

I read the documentation regarding block size and I'm not clear on how larger block sizes affect performance.

Can someone explain how large block sizes reduce performance?

Thanks.

[Jaga]

Using a larger block size in Primocache saves on overhead that would normally be lost with much smaller blocks (the more you have to track, the higher the overhead). It can also save a little bit in terms of transaction time - if you had one 64kb block to write, it would use less processing time than writing 16 4kb blocks.

On the flip-side, smaller block sizes in Primocache are generally faster for read/seek speed. If you are willing to sacrifice higher memory overhead to track the larger number of blocks, you can gain a little more performance. Of course this is largely lost when using larger files, so it's a good idea to "tune" your Cache Task to the average size of the files on the drive (just like you would when formatting the drive's cluster size).

I typically keep my Cache Task for a 4k cluster boot volume at 16kb blocks or less. But on a media storage drive with a 64k cluster format, I use a 64k block size in Primocache. Using a large block size on a large cluster formatted volume tends to keep performance high. And remember the block size in the Cache Task can never be smaller than the cluster size on the volume.

[mell111]

Makes sense. To sharpen the question a bit: what would happen with a 512k block size and 1) mostly small writes 2) mostly large writes? Will PrimoCache always wait for a block to fill up before writing to disk? Thanks.

[Jaga]

I think it'd be best to get Support to chime in on those questions.

i.e. if Primocache had a 512kb block size and only 1 byte was changed, would it re-write the entire block (in a read/write caching scenario with deferred writes) to the drive, or just the drive cluster that the single byte was changed in? I would think just the changed cluster (do some math, send the cluster to the drive, mark the block), but I've never seen it mentioned out here.

[cichy45]

I had a sequential performance problem with my 2x SSD in RAID0 serving as L2 cache. PromoCache block was set to 512KB to save memory, but SSDs were formatted using 4KB cluster size.

After reformatting them to 512KB clusters sequential performance is perfect. As I am doing mostly large file transfers, random/small file performance is less important for me but with SSD it is still way better than any HDD

[mell111]

cichy45 - first, thanks for weighing in. Would you mind elaborating?

I know that with NTFS you can set the cluster size, but looking at PrimoCache online help it appears that it's creating it's own "filesystem" in the allocated L2 cache partition and it doesn't show cluster size as an option (only block size.)

So, how did you set the cluster size? Also, did you use the built-in Windows 10 support for RAID0 or something else?

Thanks again!

[Jaga]

So, how did you set the cluster size?

I think he means he re-formatted the drives with 512kb cluster size, or used a 3rd party tool to do it.

[mell111]

"I think he means he re-formatted the drives with 512kb cluster size, or used a 3rd party tool to do it."

That's what puzzles me. Since it appears that PrimoCache does it's own formatting when you set up the L2 cache (according to the Online Help) it would overwrite the prior format. Thanks.

[cichy45]

I formatted SSD using windows tool, NTFS with 512KB cluster. I think that PrimoCache is not creating its proprietary partition, just modifying NTFS one, so I believe that clusters should remain 512KB. At least that improved performance in my case.

RAID0 is software raid, created using build-in windows tool in Disk Management, Striped Volume. Doing this will convert disks to dynamic disks.

[Support]

i.e. if Primocache had a 512kb block size and only 1 byte was changed, would it re-write the entire block (in a read/write caching scenario with deferred writes) to the drive, or just the drive cluster that the single byte was changed in? I would think just the changed cluster (do some math, send the cluster to the drive, mark the block), but I've never seen it mentioned out here.

Only changed sector (not cluster) will be written.

The cache block size is mostly affect the sequential read performance. To get the best or good sequential read performance, we recommend a cache block size equal to or smaller than a volume's file system cluster size. If the cache block size is greater than the cluster size, you might see a performance downgrade of the sequential read.

That's what puzzles me. Since it appears that PrimoCache does it's own formatting when you set up the L2 cache (according to the Online Help) it would overwrite the prior format.

He means the cluster size in a target volume. So do I. Here is nothing to do with L2 cache.