For undo-log based versioning, if there is a crash, couldn't the data be recovered from the undo log? Another question is where is the undo log stored, in memory or disk?

@gohan2021 I would guess that it depends on whether the log exists in memory or on disk, since if it's in memory it's probably not recoverable if the system crashes. If the log is stored on disk, I wonder if there still might be issues if you think about the log writing and memory writing as happening sequentially (or at least not at the exact same time), since you might have a problem if you write to memory and then your system crashes before you're able to record the previous value in memory in your undo log.

I'd guess that the undo log would be in-memory, since writing it to disk could potentially put a lot of overhead on the system. But as @ardenma said, even if you put it on disk, your system can still crash before the data actually hits disk, or even while it's occurring (as we learned in CS111, not sure where that was covered in the 110/140 sequence).

I'm a bit curious as to whether there are any HTM systems that use eager versioning; the one we went over was lazy, but I'm not sure how feasible an eager system would be.

Also curious to see how an eager HTM would handle fault tolerance issues. Would it try to maintain the data in shared cache, but only flush to main memory on commit?