Support wrote: ↑Mon Oct 31, 2022 9:37 am
PrimoCache is a block-level caching program which it only caches disk sectors and doesn't have any file information. Journaling is used in file systems and PrimoCache is very difficult to adopt such mechanism.
PS. Here "indexing" refers to PrimoCache internal indexing database for caching, not file system indexing.
PS2. We do try to make L2 safe to defer-write. This will definitely extend the usage of defer-write.
I was puzzled to learn that you are not keeping the state of the cache on L2.
What kind of data usage pattern doesn't care about integrity at all?
With SSD, there is little penalty for maintaining integrity, and implementation can be very straightforward.
Tell me, please, where I'm wrong.
1. Reserve sequential space for every block destination address and "block flush state" in L2 (8 bytes per block?).
2. When you need to write a new block in L2 - use a free or LRU flushed block space (sort index to keep LRU order).
3. When you get a flush signal for L2 blocks - flush blocks and index update in L2 before returning that flush is finished.
4. When you flush an L2 block to HDD - update the flush state in L2 asynchronously in a low-priority queue sorted by destination address.
5. When you read from HDD - stop flushing L2 to HDD, write block to L2, and update the L2 index in an async low-priority queue.
6. On shutdown - flush index updates. In case of power loss, you will only do excessive block flushing.
7. On OS start - read the whole index from L2. For 4TB L2 and 128KB blocks - it's just a 256MB file that would read in 50ms.
To have full consistency destination drive should be done as a RAW partition format over standard unformatted volume.
L2 should act as a full-size drive and hide all the logic inside the disk driver.
You don't need journaling.
Let me explain a specific use case:
- 2TB (1.5GB/s) CF cards used for RAW videos (~1Tb/hour)
- 200TB (0.6GB/s) software HDD raid volume for operational storage
- 4TB (5.0GB/s) software raid over M2 SSD drives used for ingress of data from CF and work with recent files
I have to decide when and manually move data from SSD to HDD. The hit/miss ratio on that process is not good.
And if I need it to work on moved files again - I have to copy it back to SSD, while most of the time, it's just a recent thing.
Done like in my proposal, I would expect to see the following:
1. 200TB virtual drive where I create and format partitions
2. 200TB RAW partition HDD raid for data
3. 4TB RAW partition SSD raid for the cache
Do you see any inconsistency?
I expect we will still have a ~10x cost/volume on fast vs. slow storage in the nearest future, so that 2-layer storage would be important.
Certainly, one can go with enterprise NAS with SSD cache implementations, but for mid-size, it's heavy overkill and a latency issue.
I can use tiered Storage Spaces, but the write-back cache is not used there for read caching, and tier rebalancing is not just-in-time.
And SSD caching is only available in Windows Server, so there is no solution for the desktop.
Any chance you will consider moving in that direction?
Thanks.