Re: [RFC PATCH v2] statx, inode: document the new STATX_INO_VERSION field

[Florian Weimer <fweimer@redhat.com>]

* Jeff Layton:

> All of the existing implementations use all 64 bits. If you were to
> increment a 64 bit value every nanosecond, it will take >500 years for
> it to wrap. I'm hoping that's good enough. ;)
>
> The implementation that all of the local Linux filesystems use track
> whether the value has been queried using one bit, so there you only get
> 63 bits of counter.
>
> My original thinking here was that we should leave the spec "loose" to
> allow for implementations that may not be based on a counter. E.g. could
> some filesystem do this instead by hashing certain metadata?

Hashing might have collisions that could be triggered deliberately, so
probably not a good idea.  It's also hard to argue that random
collisions are unlikely.

> It's arguable though that the NFSv4 spec requires that this be based on
> a counter, as the client is required to increment it in the case of
> write delegations.

Yeah, I think it has to be monotonic.

>> If the system crashes without flushing disks, is it possible to observe
>> new file contents without a change of i_version?
>
> Yes, I think that's possible given the current implementations.
>
> We don't have a great scheme to combat that at the moment, other than
> looking at this in conjunction with the ctime. As long as the clock
> doesn't jump backward after the crash and it takes more than one jiffy
> to get the host back up, then you can be reasonably sure that
> i_version+ctime should never repeat.
>
> Maybe that's worth adding to the NOTES section of the manpage?

I'd appreciate that.

Thanks,
Florian