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
