On Fri, Jan 22, 2021 at 09:47:53AM -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. So all metadata operations kicked off by nfsd are synchronous due to ->commit_metadata/sync_inode_metadata, so this could only happen for operations not kicked off by nfsd. More importanly ctime will also be lost as i_version and the ctime are commited together. > > 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. Ok but that is an issue if we need to deal with changes that did not come in through NFSD.
