On Sun, Nov 24, 2024 at 10:10:31PM +0000, Dr. David Alan Gilbert wrote: > * 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. ... and file fs/inode.c might have a timestamp of :01:717 so inode.o doesn't get rebuilt when it ought to have been?
