Hello, Thank you for sharing your thoughts on real-time support — it’s helpful to understand the broader direction, and I’ll certainly take that into account as development progresses.
Regarding EXT4, after some investigation, it appears there are limitations in how much we can adopt from their approach. Their journaling of timestamp updates is minimal, and much of the behavior — particularly around suppressing atime writes — is implemented at the VFS level, outside of the journaling layer. The filesystem provides mount options such as relatime, strictatime, and noatime, with relatime being the default in many environments. In practice, these often result in timestamp updates being deferred, coalesced, or entirely omitted, depending on access patterns and flush intervals (e.g., every 5 seconds). This makes it less suitable as a model for journaling fine-grained temporal updates in a real-time or user-space context. My current plan is to support both synchronous and asynchronous journaling paths, with timestamp-related changes (atime, mtime, ctime) routed exclusively through the asynchronous mechanism. Depending on how this evolves, we might later consider isolating such low-priority entries into a separate storage stream — though that remains an open question. Additionally, I intend to implement idempotent replay logic, particularly for timestamp records. For example, timestamp updates will only be applied if the recorded value is newer than the one currently present on disk, otherwise they will be treated as no-ops. This should provide robustness during recovery without compromising consistency. Best regards, Milos Nikic On Wed, Jul 2, 2025 at 9:19 AM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > Milos Nikic, le mer. 02 juil. 2025 09:01:04 -0700, a ecrit: > > The async path came first because I noticed that the vast majority > (90%+) of > > generated events were utime updates. > > We want to add relatime support :) > > > 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. > > Indeed. Probably worth checking what ext4 does about it. > > Samuel >
