Note that the "mtime" field is only tested when the NFS cache times out,
because we don't want to invalidate the cache when we write to the file
ourselves (*). The _size_ is checked a lot more often, because we can
always compare the size of the local file and the size on the server.
(*) We can't compare local mtime and server mtime for the simple reason
that they are different things - local and server time need not be
synchronized at all. Trying to make any decisions based on local and
server times leads to all kinds of problems, including _never_ timing
out the cache (very bad indeed), or timing out for no reason.
If you take a look at how Linux NFS checks the "mtime", you'll notice
that it never checks the local mtime against the server-reported mtime;
"revalidate_inode()" checks the NFS_OLDMTIME against the server-reported
mtime (and NFS_OLDMTIME is in "server time" rather than "local time").
In short, checking sizes is easy, because we have to agree on sizes (or there
is a cache problem and we should invalidate). Checking "mode" is ok too, for
the same reason. But checking "mtime" is hard do the the server and the
client having different clocks (this is the normal distributed processing
problem - the time skew between operations).
I'm not saying that the current behaviour can't be improved upon: we sure
could improve some of the heuristics. But the patches I've seen so far
aren't "it". Take a deep thought about the implications of time skew
between the different parties wrt NFS (one implication is that even
though the file changed due to _us_ doing the writing, we can't know from
the mtime)
Linus