Hello, Milos Nikic, le mar. 10 févr. 2026 10:10:44 -0800, a ecrit: > 4) I have reordered functions in the journal.h as you suggest,
I didn't mean to reorder in journal.h (thought it's still useful), but in journal.c, which is what people really read. They need that code they read there to be in the order that makes the most sense. > 9) 5-sec loop. So, periodic_sync_thread is what eventually calls > diskfs_sync_everything, and it happens every 30 seconds currently. It is a > heavy operation, and 30 second is quite a lot of time to lose in a crash. journaling is not really about the number of seconds of work you lose, but about having something *coherent* after a crash. > What we do here is add a separate shorter interval kjournal thread (similar to > what Linux does) that is much more lightweight, But then how do you provide guarantees about the ordering? > 10) Ordering of journal writes vs normal writes. Yes we do follow the correct > ordering... take a look at write_disknode_journaled function, we start the > transaction, we then call write_node() functions which is purely in memory, > then we mark dirty blocks, and then stop the transaction. Commit happens at > the > regular pace. if lazy pager (sync_everything) is called in between the commit > will also happen there. So it's the journal_block_is_active which provides the guarantee that we write to the journal before we write anything in the normal blocks? This *really* deserves a comment, since that's the precise thing that provides coherency guarantees. Writing to a log, by itself, doesn't really bring anything, it's really about enforcing the order, which ext2fs/libdiskfs contributors need to be made aware of. We'd want both a comment there for people who might be working on the ext2 pager, and a comment at the top of journal.c that gives the global overview of how things work, what gets done by who and most importantly, how we are sure that they are ordered properly. > This should make it much less likely that journal gets full. (even if > the extremely small journal is manufactured with tunefs) AIUI, now, if the journal gets full, it's journal_dirty_block that waits for it to be written back, thus blocking all threads that might be trying to push yet more log data? Again, that's worth documenting. Thanks for your work, Samuel
