Re: [PATCH] xfs: stop advertising SB_I_VERSION

[Dave Chinner <david@fromorbit.com>]

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.

> 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@kernel.org>

Thanks!

-Dave.
-- 
Dave Chinner
david@fromorbit.com