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@xxxxxxxxxxxxxxx
