Messages in this thread |  | | Date | Sat, 13 Jul 1996 11:57:34 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: NFS still has caching problem |
| |
On Thu, 11 Jul 1996, Scott Street wrote: > > Why did this check fail anyway? If (I'm looking at 2.0.0 src) linux > checks the last modified date and the size (from what I can tell in > file.c revalidate_inode(), why didn't the cache update? The date > should have changed for the "new" copy of the file. > Of course the silly answer is the date didn't change, but then isn't that > a "feature" of the NFS server?
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
|  |