Block Size Implications

FAQ, getting help, user experience about PrimoCache
User avatar
Jaga
Contributor
Contributor
Posts: 692
Joined: Sat Jan 25, 2014 1:11 am

Re: Block Size Implications

Post 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!
canceralp
Level 1
Level 1
Posts: 1
Joined: Tue Sep 29, 2020 12:22 pm

Re: Block Size Implications

Post 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.
User avatar
Support
Support Team
Support Team
Posts: 3623
Joined: Sun Dec 21, 2008 2:42 am

Re: Block Size Implications

Post 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.
libranskeptic612
Level 1
Level 1
Posts: 3
Joined: Tue Jun 02, 2020 9:33 am

Re: Block Size Implications

Post 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.
xinwei
Support Team
Support Team
Posts: 28
Joined: Mon Jan 25, 2021 8:35 am

Re: Block Size Implications

Post by xinwei »

Thank you for your suggestion.
Post Reply