Hello, Thanks for the update on this.
Milos Nikic, le ven. 18 juil. 2025 16:00:19 -0700, a ecrit: > I'm now using this system routinely without issues, But did you trash to hard-reboot your system during disk load, replay, hard-reboot during load, replay, etc. ? :) > The journaling system is structured around a single public entry point > (journal.c, journal.h). All other components are internal to libdiskfs. The > patch adds around 9 new .c files and several .h headers. Existing code changes > are limited to a few hooks in strategic places. For proper atomicity we will probably need more than just calling a function at a given point: rearrangement of disk writes might be needed. > It is designed to fail safely: if the system runs out of memory or encounters > a > journal problem, it logs a message and continues cleanly without affecting > system operation. We'd actually better make RPCs wait for the disk writes to be flushed and journal space be recovered. Otherwise we suddenly lose the safety provided by journaling. > • Replay logic: > > □ Metadata is only restored if the journaled update is newer than the > current inode mtime, and the values differ. It would probably be useful to check what ext3/4/jbd do, rather than probably make the same mistakes they did in the past :) > • Noise filtering: > > □ A hardcoded inode range excludes /dev/random, /dev/null, and other > noisy devices that would otherwise spam the journal. Which kind of operations is spamming? As I mentioned, we most probably want to implement relatime, that'll be useful to avoid many writes anyway. > Future improvements > > 1. Auto-create journal file: > > □ Detect or create RAW_DEVICE_PATH automatically if missing. Better use the ext3/4 native way of allocating blocks for the journal. > 2. Early-boot inode→path scanner: > > □ Enables path resolution before RPCs are available. > > □ Will allow smarter, full-path-based replay. Does the normal path lookup not work? At worse by rearranging some code to provide an internal version not meant for RPCs. > 3. Path-based ignore rules: > > □ Skip metadata updates for files/directories matching patterns: > > ☆ Paths like /.git/, You *don't* want to make .git unsafe. > /build/, etc. "build" risks quite a few false positives. > ☆ Extensions like .o, .a, ~, .swp These would be more commonly used indeed. Samuel
