On Fri, Jan 22, 2021 at 09:47:53AM -0500, J. Bruce Fields wrote:

quoted

quoted

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.