On Tue, Mar 18, 2025 at 11:19:52PM +0800, Alan Huang wrote: > On Mar 18, 2025, at 22:57, Kent Overstreet <[email protected]> wrote: > > In the olden days, in the before times, blacklisting insufficient > > sequence numbers would mean btree node entries could become visible > > after a crash that should've been ignored, because they were newer than > > the newest (flush) journal entry. > > > > That can't happen anymore because pointers to btree nodes now indicate > > how many sectors we've written and completed within that node, and > > they're updated after every btree node write (log append). > > > > IOW - our mechanism for sequential consistency now is that the b-tree > > behaves like a pure COW btree. > > > > So I retract what I said before :) Having just checked the journal read > > path, and the recovery path that creates the blacklist entries, I think > > we're good. > > > > The only reason we'd need to blacklist more is if we want some kind of a > > double check on the modern sequential consistency mechanism, and I don't > > think we need that. > > What about multi-btree sequential consistency ? > > i.e. one btree completes the entire tree update, but the other doesn’t
Btree updates are completed via journal updates, it's all synchronized via the journal
