On Fri, Mar 01, 2024 at 08:42:17AM -0500, Jeff Layton wrote: > On Wed, 2024-02-28 at 15:28 +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. > > > > Are you saying that XFS has timestamp granularity finer than > current_time() reports? No. > I thought XFS used the same clocksource as > everyone else. It does. > At LPC, you mentioned you had some patches in progress to use the unused > bits in the tv_nsec field as a change counter to track changes that > occurred within the same timer tick. Still a possibility, but I wasn't going to do anything in that direction because it still seemed like you were still trying to make progress down the path of generic timestamp granularity improvements. > Did that not pan out for some reason? I'd like to understand why if so. > It sounded like a reasonable solution to the problem. Time. And the fact that ctime granularity isn't SB_I_VERSION at all, so whilst we might support statx change cookies in the future, that will not be via a SB_I_VERSION mechanism. i.e. statx doesn't require us to support SB_I_VERSION for the change cookies, so until we are in a position to present a higher resolution change cookie via ctime we're just going to remove support for both. > Acked-by: Jeff Layton <jlayton@xxxxxxxxxx> Thanks! -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
