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

[Trond Myklebust <trondmy@hammerspace.com>]

On Wed, 2022-08-17 at 08:42 +1000, Dave Chinner wrote:
> 
> In XFS, we've defined the on-disk i_version field to mean
> "increments with any persistent inode data or metadata change",
> regardless of what the high level applications that use i_version
> might actually require.
> 
> That some network filesystem might only need a subset of the
> metadata to be covered by i_version is largely irrelevant - if we
> don't cover every persistent inode metadata change with i_version,
> then applications that *need* stuff like atime change notification
> can't be supported.

OK, I'll bite...

What real world application are we talking about here, and why can't it
just read both the atime + i_version if it cares?

The value of the change attribute lies in the fact that it gives you
ctime semantics without the time resolution limitation.
i.e. if the change attribute has changed, then you know that someone
has explicitly modified either the file data or the file metadata (with
the emphasis being on the word "explicitly").
Implicit changes such as the mtime change due to a write are reflected
only because they are necessarily also accompanied by an explicit
change to the data contents of the file.
Implicit changes, such as the atime changes due to a read are not
reflected in the change attribute because there is no explicit change
being made by an application.

Any implicit change in the metadata can be derived by just reading the
attribute in question: there is only 1 (atime) and it is supposed to be
monotonically increasing, hence is dead simple to detect.



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