* 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
