Jeff Layton <jlayton@xxxxxxxxxx> writes: > On Thu, 2023-08-10 at 02:44 +0900, OGAWA Hirofumi wrote: >> Jeff Layton <jlayton@xxxxxxxxxx> writes: >> > That would be wrong. The problem is that we're changing how update_time > works: > > Previously, update_time was given a timestamp and a set of S_* flags to > indicate which fields should be updated. Now, update_time is not given a > timestamp. It needs to fetch it itself, but that subtly changes the > meaning of the flags field. > > It now means "these fields needed to be updated when I last checked". > The timestamp and i_version may now be different from when the flags > field was set. This means that if any of S_CTIME/S_MTIME/S_VERSION were > set that we need to attempt to update all 3 of them. They may now be > different from the timestamp or version that we ultimately end up with. > > The above may look to you like it would always cause I_DIRTY_SYNC to be > set on any ctime or mtime update, but inode_maybe_inc_iversion only > returns true if it actually updated i_version, and it only does that if > someone issued a ->getattr against the file since the last time it was > updated. > > So, this shouldn't generate any more DIRTY_SYNC updates than it did > before. Again, if you claim so, why generic_update_time() doesn't work same? Why only FAT does? Or I'm misreading generic_update_time() patch? Thanks. -- OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
