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

From: "NeilBrown" <neilb@suse.de>
To: "Dave Chinner" <david@fromorbit.com>
Cc: "Jeff Layton" <jlayton@kernel.org>,
	"Darrick J. Wong" <djwong@kernel.org>,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	"Darrick J . Wong" <darrick.wong@oracle.com>
Subject: Re: [PATCH] xfs: fix i_version handling in xfs
Date: Thu, 18 Aug 2022 11:52:12 +1000	[thread overview]
Message-ID: <166078753200.5425.8997202026343224290@noble.neil.brown.name> (raw)
In-Reply-To: <20220818013251.GC3600936@dread.disaster.area>

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.

NeilBrown