L2 cache verification

FAQ, getting help, user experience about PrimoCache
User avatar
Jaga
Contributor
Contributor
Posts: 692
Joined: Sat Jan 25, 2014 1:11 am

Re: L2 cache verification

Post by Jaga »

Nick7 wrote: Thu Mar 11, 2021 9:52 pm @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.
I'll admit, I too expected L2 deferred data to somehow be similar to "journaled writes" (if that's the correct term to use here). In that while checking data integrity in the L2 cache at start up, if there are uncommitted writes left from the last session they'd be processed and pushed to the cached volume.

But I do trust that Romex knows their software much more intimately than we do, and there's probably a performance issue with trying to do what we expect, vs what they are doing now. Can't say that I know more than you do in this regard. :)
Mecky
Level 2
Level 2
Posts: 6
Joined: Fri Jun 11, 2021 11:22 am

Re: L2 cache verification

Post by Mecky »

In this regard, an option transparent to the user (e.g. journaled writes yes / no) would be perfect for a lot of applications, where a fast media (optane) can br written to and data integrity would be achievable in case of a power failure / system crash.
Post Reply