[OpenAFS-devel] Breaking callbacks on unlink

[Matt W. Benjamin]

Hi,

Well, it certainly could do the latter.  

Matt

----- "Simon Wilkinson" <simonxwilkinson@gmail.com> wrote:

> On 25 Feb 2012, at 23:54, Matt W. Benjamin wrote:
> 
> > 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...
> 
> By the time that the callback break arrives, the file has already
> disappeared from the view of the client. So, even with extended
> callbacks the client doesn't have a chance to grab any chunks of the
> file that it may be missing. You'd also require that a client
> constantly refresh callbacks for any files which it has open, which
> has potential fileserver performance implications.
> 
> I think any solution to this problem is going to depend upon defining
> new RPC behaviour - either for an open/close pair (which has issues
> potential issues with malicious, or disappearing clients), or in
> allowing deleted content to persist on the fileserver so that it can
> be fetched by a client receiving a callback break.
> 
> Cheers,
> 
> Simon.
> 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

-- 
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