On Thu, Feb 29, 2024 at 10:55:22AM +1100, Dave Chinner wrote: > On Wed, Feb 28, 2024 at 08:08:48AM -0800, Darrick J. Wong wrote: > > On Wed, Feb 28, 2024 at 03:28:59PM +1100, Dave Chinner wrote: > > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > > > The redefinition of how NFS wants inode->i_version to be updated is > > > incomaptible with the XFS i_version mechanism. The VFS now wants > > > inode->i_version to only change when ctime changes (i.e. it has > > > become a ctime change counter, not an inode change counter). XFS has > > > fine grained timestamps, so it can just use ctime for the NFS change > > > cookie like it still does for V4 XFS filesystems. > > > > > > We still want XFS to update the inode change counter as it currently > > > does, so convert all the code that checks SB_I_VERSION to check for > > > v5 format support. Then we can remove the SB_I_VERSION flag from the > > > VFS superblock to indicate that inode->i_version is not a valid > > > change counter and should not be used as such. > > > > > > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> > > > > Seeing as NFS and XFS' definition of i_version have diverged, I suppose > > divorce is the only option. But please, let's get rid of all the > > *iversion() calls in the codebase. > > > > With my paranoia hat on: let's add an i_changecounter to xfs_inode and > > completely stop using the inode.i_version to prevent the vfs from > > messing with us. > > Ok, I'll do that in a new patch rather than try to do everything in > a single complicated patch. Sounds good! --D > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx >
