On 2/25/2012 5:42 PM, Troy Benjegerdes wrote: > Let me propose the following: > > 1) on unlink, server broadcasts to all open callbacks something like > the following: cache_unlink_or_forget_it(), which basically informs the > client that the file is being removed.
existing afs callbacks do not contain a reason. they are sent over an unauthenticated link and cannot be trusted. what the client is told is by receipt of a callback is simply that the file server is no longer going to notify the client of changes and that something might have changed. It is entirely up to the client to decide whether or not it cares and when it does, it must issue a new FetchStatus request to find out if something in fact did change. > 2) If the client has both of the following: > a) disconnected operation > b) sufficient cache space for the whole file > > it can then pull the whole file into cache (or maybe must already have > the whole file cached), and then the server can break the callback, and > get rid of the file, and the client now has deterministic unix remove-it > on-close semantics by the time the client has received the callback it is already too late to read any more data from the file server. Attempts to read from the FileID will fail with VNOVNODE. > A possibly simpler approach is go ahead and break the callbacks on unlink, > and it's up to the client to make sure it's got enough cache space to keep > the whole file. Then it's the client's (and maybe sysadmin of the *client*) > to make sure there's enough space and something to ensure the files for > which unix unlink semantics are important for will already be cached. A saner behavior can be implemented if the file server knew the file was still in use. However, that is not possible with the IBM AFS RPC set.
signature.asc
Description: OpenPGP digital signature
