Hi, You're right — the asynchronous producer-consumer model isn't sufficient on its own for all use cases. I’ll be adding a synchronous write path next to ensure durability for critical operations.
The async path came first because I noticed that the vast majority (90%+) of generated events were utime updates. These seem well-suited to periodic async flushing (every few hundred milliseconds), since they’re high-frequency but relatively low-value — if a few timestamps are delayed or lost due to a crash, it's not a disaster. Just to clarify: this is currently meant to be a metadata-only journaling layer. Regarding format compatibility: the current binary format is experimental and Hurd-specific. I’m not aiming for ext4 compatibility at this stage — the goal is to explore journaling semantics using these structures and replay logic. If the system matures and proves useful, adapting it to the JBD/JBD2 format or interoperating with the Linux journal infrastructure would be a natural next step. Thanks again — your feedback helps sharpen both the design and direction. Best, Milos
