On Tue, Sep 06, 2022 at 01:04:05PM -0400, Jeff Layton wrote: > On Tue, 2022-09-06 at 12:41 -0400, Jeff Layton wrote: > > On Tue, 2022-09-06 at 14:17 +0200, Florian Weimer wrote: > > > * 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. > > > > > > > In principle, if a filesystem could guarantee enough timestamp > > resolution, it's possible collisions could be hard to achieve. It's also > > possible you could factor in other metadata that wasn't necessarily > > visible to userland to try and ensure uniqueness in the counter. > > > > Still... I've got one other nagging worry, about the ordering of change attribute updates with respect to their corresponding changes. I think with current implementations it's possible that the only change attribute update(s) may happen while the old file data is still visible, which means a concurrent reader could cache the old data with the new change attribute, and be left with a stale cache indefinitely. For the purposes of close-to-open semantics I think that's not a problem, though. There may be some previous discussion of this in mailing list archives. --b.
