[OpenAFS-devel] Re: Breaking callbacks on unlink

[Matt W. Benjamin]

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" <jaltman@your-file-system.com> 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