* Jeff Layton: > @@ -411,6 +413,21 @@ and corresponds to the number in the first field in one of the records in > For further information on the above fields, see > .BR inode (7). > .\" > +.TP > +.I stx_ino_version > +The inode version, also known as the inode change attribute. This > +value must change any time there is an inode status change. Any > +operation that would cause the > +.I stx_ctime > +to change must also cause > +.I stx_ino_version > +to change, even when there is no apparent change to the > +.I stx_ctime > +due to coarse timestamp granularity. > +.IP > +An observer cannot infer anything about the nature or magnitude of the change > +from the value of this field. A change in this value only indicates that > +there has been an explicit change in the inode. What happens if the file system does not support i_version? > diff --git a/man7/inode.7 b/man7/inode.7 > index 9b255a890720..d5e0890a52c0 100644 > --- a/man7/inode.7 > +++ b/man7/inode.7 > @@ -184,6 +184,18 @@ Last status change timestamp (ctime) > This is the file's last status change timestamp. > It is changed by writing or by setting inode information > (i.e., owner, group, link count, mode, etc.). > +.TP > +Inode version (i_version) > +(not returned in the \fIstat\fP structure); \fIstatx.stx_ino_version\fP > +.IP > +This is the inode change attribute. Any operation that would result in a change > +to \fIstatx.stx_ctime\fP must result in a change to this value. The value must > +change even in the case where the ctime change is not evident due to coarse > +timestamp granularity. > +.IP > +An observer cannot infer anything from the returned value about the nature or > +magnitude of the change. If the returned value is different from the last time > +it was checked, then something has made an explicit change to the inode. What is the wraparound behavior for i_version? Does it use the full 64-bit range? If the system crashes without flushing disks, is it possible to observe new file contents without a change of i_version? Thanks, Florian
