February 26, 2026 at 7:55 PM, "Milos Nikic" <[email protected] mailto:[email protected]?to=%22Milos%20Nikic%22%20%3Cnikic.milos%40gmail.com%3E > wrote:
> > OK thanks, > > I think this is now completed. Thanks for working on this Milos! I'm looking forward to seeing /hurd/ext3fs or /hurd/ext4fs! And speaking as a Hurd user (not a developer) that uses SSDs, I don't know that I will notice a 10% slowdown, but I'll be very glad to have a journal! > All the file system operations are hooked up. > We have progressive check pointing that works. > ensure_blocks_committed is a barrier that guarantees WAL, and its documented > in the code (with some caveats) > > I did some bench-marking and while normal operations on files seem the > same...we can observe a difference when heavy operations happen > specifically if they change same disk blocks multiple times and this pager > forces a commit a bit more often. > For instance when one is compiling Hurd. > I have experienced it about 8.5% slower compilation than when journal is not > present. (and ~12% slower when running ./configure for instance), > but 0% slower when mass deleting files or just going about my business. > Its a large patch now...let me know if you want it split up. > > I have rearranged the functions in journal.c to follow the flow. I have > documented a lot. > Let me know what you think! > > Thanks, > Milos > > On Wed, Feb 25, 2026 at 4:32 PM Samuel Thibault <[email protected] > mailto:[email protected] > wrote: > > > > > Hello, > > > > Milos Nikic, le mar. 24 févr. 2026 20:35:58 -0800, a ecrit: > > > Progressive check-pointing is now working greatly, journal is most of the > > > time > > > (almost) empty! > > > > Cool :) > > > > > We now have new failure modes, for instance what happens if we are not > > > able to > > > commit the transaction? > > > Or if we cannot add new buffer to the existing transaction. > > > Lets say we cannot allocate a buffer? > > > this is all happening under diskfs_node_update... > > > We have multiple options here: > > > 1) Panic, journal is in inconsistent state, we cannot guarantee soundness > > > of > > > the system. > > > Maybe extreme, but a possibility > > > > I don't see why it would be inconsistent? Sure, if there is a crash, we > > cannot guarantee the soundness, but provided that the normal flushing to > > disk works fine, the state will be alright. > > > > > 2) Issue a warning and continue, things will be written to the file system > > > without being journaled eventually, not great. > > > > Not ideal it terms of safety against crashes, but will work fine, and > > once memory is back, we will be back with safe journaling. > > > > > 3) This is a suble one, we could bubble up the error and let the VFS code > > > decide what it wants to do. For instance > > > It we failed during atime update, no need to panic, but if the rename has > > > gone > > > bad, that is a different story. > > > For that we would need to change what diskfs_node_update to return > > > error_t, > > > which would require touching many files. > > > > And we will miss many cases etc. it seems very risky to me. > > > > Samuel > > >
