Messages in this thread | | | From | Florian Weimer <> | Subject | Re: [RFC PATCH v2] statx, inode: document the new STATX_INO_VERSION field | Date | Thu, 01 Sep 2022 18:12:33 +0200 |
| |
* 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
| |