Page 2 of 2

Re: Block Size Implications

Posted: Wed Oct 31, 2018 8:49 am
by Jaga
support wrote: Wed Oct 31, 2018 5:51 am
Jaga wrote: Tue Oct 23, 2018 5:11 am 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 makes perfect sense, thanks for the clarification. Learned something new about Primocache too!

Re: Block Size Implications

Posted: Tue Sep 29, 2020 12:27 pm
by canceralp
Jaga wrote: Wed Oct 31, 2018 8:49 am
support wrote: Wed Oct 31, 2018 5:51 am
Jaga wrote: Tue Oct 23, 2018 5:11 am 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 makes perfect sense, thanks for the clarification. Learned something new about Primocache too!
Sorry for necroing thread. I am about to buy Primocache (I have 25 days left for the trial edition). One think bothered me; if chancing block size would degrade the SSD faster, way faster.. According to this quote "only changed sector (not cluster) will be written", can we safely say that 512Kb and 4Kb block sizes has no effect on SSD lifespan?

BTW, for a 5400rpm 2TB WD hdd and Samsung Evo 500GB Sata SSD, block size doesn't make any difference.

Re: Block Size Implications

Posted: Wed Sep 30, 2020 2:21 am
by Support
canceralp wrote: Tue Sep 29, 2020 12:27 pm According to this quote "only changed sector (not cluster) will be written", can we safely say that 512Kb and 4Kb block sizes has no effect on SSD lifespan?
If the SSD is used for write-caching only, I think yes. But for reading cache, PrimoCache always tries to fetch whole block data from the source disk. So 521KB size may cause more write wear than 4KB, when the ssd is used as L2 cache cache.

Re: Block Size Implications

Posted: Wed Apr 07, 2021 5:27 am
by libranskeptic612
If e,g., a small 256GB ssd were caching a large 4tb (2x2tb) HDD array, then this small cache space ought prioritise the most painfully slow blocks on the hdd array.

In the large linear files this rig would suit, these blocks are those at the beginning of each contiguous file. The read head needs to track to the file start point.

So if a hdd access time is usually 15ms, then the first 15ms of the files data should be cached, & it would be good if that 15ms of data could involve minimal operations.

Re: Block Size Implications

Posted: Thu Apr 08, 2021 2:47 am
by xinwei
Thank you for your suggestion.