On Fri, Jan 22, 2021 at 08:20:59AM +0000, Christoph Hellwig wrote: > On Thu, Jan 21, 2021 at 03:27:56PM -0500, J. Bruce Fields wrote: > > I also have a vague idea that some filesystem-specific improvements > > might be possible. (E.g., if a filesystem had some kind of boot count > > in the superblock, maybe that would be a better way to prevent the > > change attribute from going backwards on reboot than the thing > > generic_fetch_iversion is currently doing with ctime. But I have no > > concrete plan there, maybe I'm dreaming.) > > Even without the ctime i_version never goes backward, what is the > problem here? Suppose a modification bumps the change attribute, a client reads the new value of the change attribute before it's committed to disk, then the server crashes. After the server comes back up, the client requests the change attribute again and sees an older value. That's actually not too bad. What I'd mainly like to avoid is incrementing the change attribute further and risking reuse of an old value for a different new state of the file. Which is why generic_fetch_iversion is adding the ctime in the higher bits. So we depend on good time for correctness. Trond has had some concerns about that. Something like a boot counter might be more reliable. Another interesting case is after restore from backup. --b.
