Romex Software Forum

I've configured my Primo cache such that the RAM portion of the cache does not accept any writes (0% writes) and my NVME cache accepts them. I assume, then, that the "deferred" writes are in the NVME portion. So... do those writes survive an unexpected reboot? Ie: after the reboot, do they get written?

I just realized that I posted these two questions in "Primo Ramdisk" tech support not... where they belong in "Primo Cache" tech support .

Primocache can be touchy where the integrity of the cache blocks (and even more with deferred writes) is concerned, and for good reason. Normally at shut-down they'd get written so there are no outstanding writes queued in the task. And your assumption is correct - the writes would skip the L1 entirely and head straight for the L2.

There are several different scenarios at boot where it decides flushing the entire cache task is warranted, and I don't remember all of them. If memory serves that list has changed more than once over the last few years. Even something as innocuous as defragmenting the pagefile and MFT can trigger a flush (any offline changes to the drive essentially). I can distinctly remember many times a few years ago (with a less stable machine) where BSODs and other unplanned reboots did trigger a flush.

I did find official mention of how the L2 tracks blocks:

PrimoCache implements a mechanism to check if cache contents stored in level-2 storage are synced with source disks. It traces and updates flags saved in Windows registry

Based on this information, I'd assume that any outstanding deferred writes would be marked as dirty blocks in the L2 since, and discarded at the next boot. The entire L2 may be marked dirty since it's out of sync, hard to say. Best to assume my answer is opinion and wait for Support to give the specifics.

I'm sorry that so far the risk is same whether you use L1 or L2 for defer-write. On an unexpected shutdown, deferred-write data in L2 will be lost and don't get recovered.
We are working to try to reduce the data loss risk on L2 defer-write, able to recover deferred write-data as possible. I hope this feature can come out soon.

One thing that would be nice for dealing with a lost deferred write on a crash/reboot would be an alert. The program can alert the user that a crash/reboot occurred and there may be data corruption and a lit of effected files. The user can now validate these files and perform any needed recovery. This is very important to prevent any sort of silent data corruption from forming. Ideally such an alert could be emailed directly to the user so they are immediately informed of possible data corruption and can begin the recovery process.

@zeroibis, thanks for your suggestion!