I was thinking about something like Tinval (asks the server for invalidations for files seen) Rinval (reports new invalidations) Tinval (asks for further invals, and let the server know that Rinval was seen by client)
This is similar to the "changes" file proposed above, but it´s simple, does not require two new RPCs (a server would respond to a Tinval with an Rerror (unknown request or whatever), is not an upcall (although behaves as one) and may both let the client know which files changed and which cache entries are invalid. We did consider this, but having all terminals connected to slow links to the central fs means that all fs activity might be slowed down by the link with worst latency. However, my experience using this thing says that (at least in my case) I´m using at most one remote terminal at a time, or a bunch of well connected terminals. Which might suggest that this Tinval thing might pay. Time to experiment, perhaps. On 11/1/07, Sape Mullender <[EMAIL PROTECTED]> wrote: > > Why not just have a file that a client reads that lets the client know > > of changes to files. > > A bit better, but the comment I just made about breaking single-copy > semantics still hold. The point is that merely notifying the client > isn't enough. The server should wait for an acknowledgement to that > notification (which possibly doesn't arrive until after the client has > flushed its updates from the cache). > > Sape > >
