I recently built a desktop computer, and wanted to revisit Primocache as a 'landing zone' for a slew of external 8tb SMR hard drives.
I'm not interested in caching, or L1 memory at all, I just want to use a 500GB SSD RAID-0 as a write-buffer for my slow disks.
Like the title says, I don't understand why (when not wanting read-buffer at all) primocache still requires GB's of physical memory to achieve a reasonably small block size?
I understand using physical memory as a sort of 'index' of the cache contents, but I do not want read-cache at all. Only write.
Why does L2 deferred write eat physical memory? Topic is solved
-
- Level 1
- Posts: 4
- Joined: Tue Aug 21, 2018 1:33 pm
Re: Why does L2 deferred write eat physical memory?
I'm just user, so it just assumption.
SSD write buffer for HDD. It still cache, just in another direction.
It anyway need to write data to ssd, primocache use it's own file system, which need ram for maintain index of cache data.
In other word, after write to ssd, it works as read cache for transfer data to hdd.
SSD write buffer for HDD. It still cache, just in another direction.
It anyway need to write data to ssd, primocache use it's own file system, which need ram for maintain index of cache data.
In other word, after write to ssd, it works as read cache for transfer data to hdd.
Re: Why does L2 deferred write eat physical memory?
Indexing. The more blocks, the larger the index. It maps blocks (Primocache) to groups of clusters (volume), and the more of them it has to map, the larger the memory use is. It also saves state information (like unwritten/written), and probably other information on the blocks.fattipants2016 wrote: ↑Wed Dec 12, 2018 2:14 pmLike the title says, I don't understand why (when not wanting read-buffer at all) primocache still requires GB's of physical memory to achieve a reasonably small block size?
-
- Level 1
- Posts: 4
- Joined: Tue Aug 21, 2018 1:33 pm