On Tue, Aug 16, 2022 at 09:43:16AM -0400, Jeff Layton wrote: > On Tue, 2022-08-16 at 15:33 +0200, Christian Brauner wrote: > > On Tue, Aug 16, 2022 at 09:15:22AM -0400, Jeff Layton wrote: > > > ext4 currently updates the i_version counter when the atime is updated > > > during a read. This is less than ideal as it can cause unnecessary cache > > > invalidations with NFSv4. The increment in ext4_mark_iloc_dirty is also > > > problematic since it can also corrupt the i_version counter for > > > ea_inodes. > > > > > > We aren't bumping the file times in ext4_mark_iloc_dirty, so changing > > > the i_version there seems wrong, and is the cause of both problems. > > > Remove that callsite and add increments to the setattr and setxattr > > > codepaths (at the same time that we update the ctime). The i_version > > > bump that already happens during timestamp updates should take care of > > > the rest. > > > > > > Cc: Lukas Czerner <lczerner@xxxxxxxxxx> > > > Cc: Jan Kara <jack@xxxxxxx> > > > Cc: Christian Brauner <brauner@xxxxxxxxxx> > > > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> > > > --- > > > > Seems good to me. But it seems that the xfs patch you sent does have > > inode_inc_version() right after setattr_copy() as well. So I wonder if > > we couldn't just try and move inode_inc_version() into setattr_copy() > > itself. > > > > We probably could, but setattr_copy has a lot of callers and most > filesystems don't need this. Also, there are some cases where we don't > want to update the i_version after a setattr. > > In particular, if you do a truncate and the size doesn't change, then > you really don't want to update the timestamps (and therefore the > i_version shouldn't change either). We could probably all handle that with some massaging but I'm also fine with doing it just for ext4 and xfs if these are the only ones where this is relevant: Reviewed-by: Christian Brauner (Microsoft) <brauner@xxxxxxxxxx>
