Romex Software Forum

Hi,
Zerofootprint cache is a concept used by Adaptiva Onesite product.
It's described here: https://www.anoopcnair.com/achieve-foot ... sues-sccm/
Same concept could be used by L2 cached. (Assumes disk volume for other purposes.)

How it looks like:
1. To OS (resp. disk reporting tools) the space appears to be free.
2. If OS or applications try to allocate that space, caching mechanism silently releases the space.

Hence:
1. Cache consumes virtually no space on the disk. (or a minimum you want to have "reserved".)
2. The cache can be technically as big as all free space on disk volume.

At this point I cannot imagine that similar concept could be useful for L1 caching. (resp. why to pretend there's a free memory and why to de-allocate/decrease cache under pressure.) ... but maybe I am missing something.

Thank you for sharing the information!

This sounds like DMM feature of Ramdisk just working the other way around.

points wrote: ↑Wed Jun 26, 2019 5:09 am This sounds like DMM feature of Ramdisk just working the other way around.

Almost. It's not only dynamic, but also perfectly seamless from disk capacity perspective, potentially using your SSD to the max... Costing you some L2 performance, of course...

Surely almost. It wasn't meant to be a 1:1 comparison. It's just like if there is a similar feature already maybe it is not to hard too implement it.
However correct implementation seems to be crucial. Especially when working with encrypted data. It would be a disaster if such a feature fills entire disks up with decrypted data for caching without the user knowing instead of encrypted data. For such use cases it must be ensured that encryption stays intact and only encrypted data gets cached.

Encryption is for sure relevant requirement, however the issues is there with current L2 caching.
This (hypothetical) feature does not make it worse or better.

From a techincal standpoint yes.
I was thinking about the implication for the user. From the description it seems that this process is invisible for the user. So he is not aware that much more data is cached (potentially unencrypted on the disk) than he might have set the cache size to. If it goes really bad the entire disk resides unencrypted in the invisible L2 storage instead just in the small portion the user has assigned to. Also many users are not very much skilled when it comes to deletion. A user might be under the impression that deletion removes the cache. But with that feature implemented in a wrong way, much unencrypted date could remain on the disk without the user even suspecting.
Therefore I believe the potential implementation of such feature must be done very thoughtful and thoroughly. If I remember correctly the first versions of Primocache did not support encryption and stored encrypted data unencrypted in L2 storage. That's even worse as L2 storage is mostly SSD which means once stored deletion by normal means is not possible. So that's something a software engineer normally should never ever even think of implementing in such a way.