That makes perfect sense, thanks for the clarification. Learned something new about Primocache too!support wrote: ↑Wed Oct 31, 2018 5:51 amOnly changed sector (not cluster) will be written.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.
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.
Block Size Implications
Re: Block Size Implications
Re: Block Size Implications
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?Jaga wrote: ↑Wed Oct 31, 2018 8:49 amThat makes perfect sense, thanks for the clarification. Learned something new about Primocache too!support wrote: ↑Wed Oct 31, 2018 5:51 amOnly changed sector (not cluster) will be written.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.
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.
BTW, for a 5400rpm 2TB WD hdd and Samsung Evo 500GB Sata SSD, block size doesn't make any difference.
Re: Block Size Implications
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.
-
- Level 1
- Posts: 3
- Joined: Tue Jun 02, 2020 9:33 am
Re: Block Size Implications
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.
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
Thank you for your suggestion.