[OpenAFS-devel] Breaking callbacks on unlink
Simon Wilkinson
simonxwilkinson@gmail.com
Sun, 26 Feb 2012 00:45:17 +0000
On 25 Feb 2012, at 23:54, Matt W. Benjamin wrote:
> well,
>=20
> 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)
>=20
> 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.