Yeah, I don't think it's worth trying for perfect consistency between a local application using mmap and a remote NFS client.
"The answer for people trying to enforce cache-coherency across multiple clients has always been "use POSIX locking". If we simply have nfsd force the c/mtime update whenever a lock is released then that may be enough keep that in check."
That might not be a bad idea.
For ordinary NFS clients the requirement that "times must be updated between any write to a page and either the next msync() call or the writeback of the data in question" may be all we need to guarantee that clients will see updates when they should, as they should normally be committing data before unlocking or opening. (Though I wonder about the case where they hold a write delegation.)
"that change doesn't necessarily need to move toward the future."
Though in the v4 case there's a chance the change attribute could repeat a value after reboot. I wonder if the filesystem could somehow add N to all change attributes after an unclean shutdown, for some big enough N.
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds