Re: [PATCH] xfs: fix i_version handling in xfs

From: Trond Myklebust <trondmy@hammerspace.com>
To: "david@fromorbit.com" <david@fromorbit.com>,
	"neilb@suse.de" <neilb@suse.de>
Cc: "darrick.wong@oracle.com" <darrick.wong@oracle.com>,
	"djwong@kernel.org" <djwong@kernel.org>,
	"jlayton@kernel.org" <jlayton@kernel.org>,
	"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] xfs: fix i_version handling in xfs
Date: Thu, 18 Aug 2022 02:22:15 +0000	[thread overview]
Message-ID: <c77a3f07e45f0c99019517f3b92d0bdbecf884af.camel@hammerspace.com> (raw)
In-Reply-To: <166078753200.5425.8997202026343224290@noble.neil.brown.name>

On Thu, 2022-08-18 at 11:52 +1000, NeilBrown wrote:
> On Thu, 18 Aug 2022, Dave Chinner wrote:
> > 
> > > Maybe we should just go back to using ctime.  ctime is *exactly*
> > > what
> > > NFSv4 wants, as long as its granularity is sufficient to catch
> > > every
> > > single change.  Presumably XFS doesn't try to ensure this.  How
> > > hard
> > > would it be to get any ctime update to add at least one
> > > nanosecond?
> > > This would be enabled by a mount option, or possibly be a direct
> > > request
> > > from nfsd.
> > 
> > We can't rely on ctime to be changed during a modification because
> > O_NOCMTIME exists to enable "user invisible" modifications to be
> > made. On XFS these still bump iversion, so while they are invisible
> > to the user, they are still tracked by the filesystem and anything
> > that wants to know if the inode data/metadata changed.
> > 
> 
> O_NOCMTIME isn't mentioned in the man page, so it doesn't exist :-(
> 
> If they are "user invisible", should they then also be "NFS
> invisible"?
> I think so.
> As I understand it, the purpose of O_NOCMTIME is to allow
> optimisations
> - do a lot of writes, then update the mtime, thus reducing latency. 
> I
> think it is perfectly reasonable for all of that to be invisible to
> NFS.

The point is that you can always detect an implicit metadata change by
just reading the attribute that changed. The case of an explicit change
is different, because the application might be changing the value back
to a previous setting. The entire value of ctime is that it allows you
to know not to trust any caches when this might be the case because it
records the fact that there was an explicit data or metadata change
somewhere along the line.

By discarding that information about explicit vs implicit changes, XFS
is making the i_version less useful to applications that need to cache
data and/or metadata. So the real question is: for which real world
applications is this behaviour adding value that could not be derived
through other means?

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com