Re: [PATCH] xfs: stop advertising SB_I_VERSION

From: Jeff Layton <jlayton@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs@vger.kernel.org, djwong@kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] xfs: stop advertising SB_I_VERSION
Date: Sun, 03 Mar 2024 19:45:36 -0500	[thread overview]
Message-ID: <b18393ebab290ddd83b22830096796b829568225.camel@kernel.org> (raw)
In-Reply-To: <ZeUJWuO8TkuoodIx@dread.disaster.area>

On Mon, 2024-03-04 at 10:35 +1100, Dave Chinner wrote:
> 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@redhat.com>
> > > 
> > > 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.
> 

Ok, good. I'm glad to hear that that approach isn't unworkable (yet!).

As far as timestamp granularity goes, Linus made it clear that he was
not on board with any approach that would even more complexity than the
original multigrain ctime patches. That pretty much ended my work in
that area.

> > 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.
>

Yeah, that makes sense.

> > Acked-by: Jeff Layton <jlayton@kernel.org>
> 
> Thanks!
> 
> -Dave.

-- 
Jeff Layton <jlayton@kernel.org>