Defer-Write with L1 and L2

FAQ, getting help, user experience about PrimoCache
wave
Level 3
Level 3
Posts: 19
Joined: Sat Oct 23, 2021 7:07 pm

Re: Defer-Write with L1 and L2

Post by wave »

Support wrote: Tue Oct 26, 2021 3:59 am
Styx wrote: Mon Oct 25, 2021 3:25 pm May I suggest an advanced option when Defer-write is enabled using an L2 cache ?
The option would be: "persist dirty block map" and when enabled, it would actually flush the dirty block map on the L2 cache (persistent) each time a time interval specified by Latency expires.
This way, it allows a user to use the defer-write with some level of protection against data loss (i.e max data loss = latency, so if you set latency to 5s, then you can lose up to 5s of data in case of a system crash).
Currently, whether using L1 or L2, max data loss = latency (though it is possible that lost data is updated file system metadata by chance). What we think and other users request is to make L2 defer-write 100% no loss, able to recover data after a crash. That's complicated.
Right. I misread. I also meant to make L2 defer-write 100% no loss, able to recover data after a crash.
Support wrote: Tue Oct 26, 2021 3:59 am That's complicated.
I guess the problem is that system files would be changed on reboot before primocache can finish its job making it virtually impossible. But it can be solved by creating a primocache boot disk to complete the cache flush before starting windows ;)
thc
Level 2
Level 2
Posts: 8
Joined: Sat Oct 23, 2021 9:37 pm

Re: Defer-Write with L1 and L2

Post by thc »

In an 'optimized' Windows with everything that is not needed deactivated, services, tasks, ..., and by means of soft type 'FolderChangesView', we see that Windows writes are practically reduced to the obligatory fucking event logs/traces and little else (in fact, this Win11 is surprising me, after several hours in idle mode there is no disk I/O request, bravo!). Personally, I have had updated data in cache for several days and after system crashes (caused by memory timings that are too low, as always), 75% of the time Windows has restarted perfectly. In the remaining 25%, I did not even need to resort to the commands 'sfc /scannow' and its subsequent 'dism /online /cleanup-image /restorehealth', only the Windows registry has been corrupted.

Conclusion: Obviously in the face of power losses or system crashes, Windows does not usually rewrite critical system data, and even in this situation, there are several and effective countermeasures (WinSxS). It counts on the part of the common sense of the user to know when to flush the updated data.
Post Reply