Messages in this thread | | | From | (Thomas Schoebel-Theuer) | Subject | Re: NFS still has caching problem | Date | 14 Jul 1996 14:20:07 GMT |
| |
In article <Pine.LNX.3.91.960713114750.11189B-100000@linux.cs.Helsinki.FI>, Linus Torvalds <torvalds@cs.helsinki.fi> writes: |> 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).
As far as I understood the problem, we simply want to notice when something on the *server* has changed. So it would be enough to compare the *old server* mtime against the *new server* mtime. No comparsions with client times, just times valid on the server, so we need not add any time offsets. Moreover, it should suffice to compare for non-equality, not for higher/lower time.
|> 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)
Of course, it is theoretically possible that a client modifies something and because of time skew the mtime doesn't change at all. But we are talking about an additional criterion to recognize changes. The additional comparison of mtime should improve things, IMHO, as compared to the current state.
To implement it, we just have to keep the old mtime (unmodified) from the server in an extra field. Any time a new update is received by the client, we simply check whether it has changed. This check could be inhibited if the change were due to ourselves; in this case it is less reliable. Perhaps somebody has an idea to improve this case without having to deal with time skews?
-- Thomas
| |