[Linus Cc'd] On Sun, Nov 24, 2024 at 06:56:57PM +0100, Mateusz Guzik wrote: > However, since both sec and nsec are updated separately and there is no > synchro, reading *both* can still result in values from 2 different > updates which is a bug not addressed by any of the above. To my > underestanding of the vfs folk take on it this is considered tolerable. Well... You have a timestamp changing. A reader might get the value before change, the value after change *or* one of those with nanoseconds from another. It's really hard to see the scenario where that would be a problem - theoretically something might get confused seeing something like Jan 14 1995 12:34:49.214 -> Jan 14 1995 12:34:49.137 -> Nov 23 2024 14:09:17.137 but... what would that something be? We could add a seqcount, but stat(2) and friends already cost more than they should, IMO... Linus, do you see any good reasons to bother with that kind of stuff? It's not the first time such metadata update vs. read atomicity comes up, maybe we ought to settle that for good and document the decision and reasons for it. This time it's about timestamp (seconds vs. nanoseconds), but there'd been mode vs. uid vs. gid mentioned in earlier threads.
