On Mon, Sep 12, 2022 at 10:02:27AM -0400, Jeff Layton wrote: > On Mon, 2022-09-12 at 09:51 -0400, J. Bruce Fields wrote: > > On Mon, Sep 12, 2022 at 08:55:04AM -0400, Jeff Layton wrote: > > > Because of the "seen" flag, we have a 63 bit counter to play with. Could > > > we use a similar scheme to the one we use to handle when "jiffies" > > > wraps? Assume that we'd never compare two values that were more than > > > 2^62 apart? We could add i_version_before/i_version_after macros to make > > > it simple to handle this. > > > > As far as I recall the protocol just assumes it can never wrap. I guess > > you could add a new change_attr_type that works the way you describe. > > But without some new protocol clients aren't going to know what to do > > with a change attribute that wraps. > > > > Right, I think that's the case now, and with contemporary hardware that > shouldn't ever happen, but in 10 years when we're looking at femtosecond > latencies, could this be different? I don't know. That doesn't sound likely. We probably need not just 2^63 writes to a single file, but a dependent sequence of 2^63 interspersed writes and change attribute reads. Then there's the question of how many crashes and remounts are possible for a single filesystem in the worst case. > > > I think this just needs to be designed so that wrapping is impossible in > > any realistic scenario. I feel like that's doable? > > > > If we feel we have to catch that case, the only 100% correct behavior > > would probably be to make the filesystem readonly. > > What would be the recourse at that point? Rebuild the fs from scratch, I > guess? I guess. --b.
