* Al Viro (viro@xxxxxxxxxxxxxxxxxx) wrote: > [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? make? i.e. if the change was from: a) mmm dd yyyy hh::MM::00:950 -> b) mmm dd yyyy hh::MM::01:950 -> c) mmm dd yyyy hh::MM::01:200 -> If you read (b) then you'd think that the file was 750ms newer than it really was; which is a long time these days. Dave > 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. > -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ dave @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/
