So Defer-Write>>L2Cahe>>system crash and now how primocache gona deal with it after reboot?
Discard data that was written to L2 or save it on cached disk?
L2 cache verification
Re: L2 cache verification
A power outage or system failure might result in data loss or corruption because in such scenarios the cache has no chance to write data back to the disk.
For more details,please see https://www.romexsoftware.com/en-us/pri ... ation.html
For more details,please see https://www.romexsoftware.com/en-us/pri ... ation.html
Re: L2 cache verification
Im asking about new function of L2 verification and how it works with defer-write.xinwei wrote: ↑Wed Mar 10, 2021 8:17 am A power outage or system failure might result in data loss or corruption because in such scenarios the cache has no chance to write data back to the disk.
For more details,please see https://www.romexsoftware.com/en-us/pri ... ation.html
Re: L2 cache verification
L2 verification is only to verify the data stored at the last good bootup.it does not verfiy deferred write-data during the run time. A power outage or system failure still might result in data loss or corruption.There is no connection between them.
Re: L2 cache verification
New: Verify level-2 cache data on the next boot after an ungraceful shutdown, instead of simply cleaning all level-2 cache data. Quote from changelog.
Please stop posting things that are not answers to my question.
Re: L2 cache verification
Please note that L2 verification is only to verify L2 data stored right at the last bootup, not the data stored before the ungraceful shutdown. Here is a detailed explaination for this. viewtopic.php?p=15667#p15667
Deferred write-data are stored after bootup, so they will not be verified and just discarded, as before.
Deferred write-data are stored after bootup, so they will not be verified and just discarded, as before.
Re: L2 cache verification
Wow.. that's.. really odd design!xinwei wrote: ↑Thu Mar 11, 2021 8:35 am Please note that L2 verification is only to verify L2 data stored right at the last bootup, not the data stored before the ungraceful shutdown. Here is a detailed explaination for this. viewtopic.php?p=15667#p15667
I mean, data pointers, etc.. that is written to L2 storage may be completely different than currently is in L2 cache itself. Even data for specific block.
What this basically seems/means is - you need to re-read all data from disk, and again re-fill L2 cache by using just pointers to disk where that data is.
All in all, it's quite weird design, and many other caching algorithms/software does it better/differently.
I do hope this changes, as well as if only using L2 (without L1) for defer-writes, in case of crash, data will remain safe in L2 and will be written down once system is back up.
Re: L2 cache verification
Thank you for pointing to an answer.xinwei wrote: ↑Thu Mar 11, 2021 8:35 am Please note that L2 verification is only to verify L2 data stored right at the last bootup, not the data stored before the ungraceful shutdown. Here is a detailed explaination for this. viewtopic.php?p=15667#p15667
Deferred write-data are stored after bootup, so they will not be verified and just discarded, as before.
I agree, its weird.Nick7 wrote: ↑Thu Mar 11, 2021 11:01 am
Wow.. that's.. really odd design!
I mean, data pointers, etc.. that is written to L2 storage may be completely different than currently is in L2 cache itself. Even data for specific block.
What this basically seems/means is - you need to re-read all data from disk, and again re-fill L2 cache by using just pointers to disk where that data is.
All in all, it's quite weird design, and many other caching algorithms/software does it better/differently.
I do hope this changes, as well as if only using L2 (without L1) for defer-writes, in case of crash, data will remain safe in L2 and will be written down once system is back up.
Last sentence is what i thought when i read the changelog for version 4.0.1.
I hope they change this, it would be so handy for trash writes to ssd (for example a 16gb optane drive as L2, they are so cheap like 5 euro or less)
Re: L2 cache verification
Here's what I take away from it (and have sorta lived by the entire time I've been using Primocache/Fancycache): If you are going to use deferred writes, you'd better have a very reliable and solid system. While I agree a different mechanism for data verification on deferred data would be useful, I still don't think I'd rely on any software that I wasn't prepared to support by giving it a rock-solid platform to run on.Nick7 wrote: ↑Thu Mar 11, 2021 11:01 am...What this basically seems/means is...xinwei wrote: ↑Thu Mar 11, 2021 8:35 am Please note that L2 verification is only to verify L2 data stored right at the last bootup, not the data stored before the ungraceful shutdown. Here is a detailed explaination for this. viewtopic.php?p=15667#p15667
I can't remember the last time I had an ungraceful shutdown, a BSOD, a fatal error, etc. Probably not the entire time I've been using & supporting clients in Windows 10. In my opinion, it's very important to take time to keep a system you care about well tuned, updated, and cared for. If you don't it can start to exhibit undesirable symptoms, which can affect your data in ways you really don't want.
Anyhow, if I had a recommendation for anyone looking to speed up their machine(s) with deferred writes, it would be to fully stabilize your system first, and only after doing so consider turning the feature on. Additionally, prior to system shutdown it can be useful to manually open Primocache's UI and force a flush on any deferred data, just in case you think there is any question of whether or not there's important data in the cache left unwritten.
Re: L2 cache verification
@Jaga - i partly agree. I agree data integrity should be 1st. This is why using L2 for defer writes can be still safe. Take bcache as an example. It did it right.
On the other hand - we also talked here about L2 read cache, and how crash handles that. Saying that L2 'resets' (I know it's wrong word, but it's been said before) on crash is silly. L2 should be in a state when crash happened. Even if consequent rescan for all data in L2 is done, fine. But don't reset to 'last know boot' state.
On the other hand - we also talked here about L2 read cache, and how crash handles that. Saying that L2 'resets' (I know it's wrong word, but it's been said before) on crash is silly. L2 should be in a state when crash happened. Even if consequent rescan for all data in L2 is done, fine. But don't reset to 'last know boot' state.