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

From: Dave Chinner <david@fromorbit.com>
To: NeilBrown <neilb@suse.de>
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 13:00:48 +1000	[thread overview]
Message-ID: <20220818030048.GE3600936@dread.disaster.area> (raw)
In-Reply-To: <166078753200.5425.8997202026343224290@noble.neil.brown.name>

On Thu, Aug 18, 2022 at 11:52:12AM +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.

Maybe, but now you're making big assumptions about what is being
done by those operations. Userspace can write whatever it likes,
nothing says that O_NOCMTIME can't change user visible data or
metadata.

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

O_NOCMTIME is used by things like HSMs, file defragmenters,
deduplication tools, backup programs, etc to be able to read/write
data and manipulate file layout without modifying user visible
timestamps. i.e. users shouldn't notice that the online defragmenter
defragmented their file. Backup programs shouldn't notice the
defragmenter defragmented the file. 

But having uses of it that don't change user visible data does not
mean it can't be used for changing user visible data. Hence we made
the defensive assumption that O_NOCMTIME was a mechanism that could
be used to hide data changes from forensic analysis. With that in
mind, it was important that the change counter captured changes made
even when O_NOCMTIME was specified to leave behind a breadcrumb to
indicate unexpected changes may had been made to the file.

Yeah, we had lots of different requirements for the XFS on-disk
change counter when we were considering adding it. NFSv4 was one of
the least demanding and least defined requirements; it's taken a
*decade* for this atime issue to be noticed, so I really don't think
there's anything wrong with how XFs has implemented persistent
change counters.

What it tells me is that the VFS needs more appropriate atime
filtering for NFSv4's change attribute requirements....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com