well, 1. the response to unlink w/XCB is an indication of unlink 2. if rxgk is in use (there is published code of at least alpha quality implementing, iirc, rxgk with callback channel protection)
So... Matt ----- "Jeffrey Altman" <[email protected]> wrote: > 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. -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
