[OpenAFS] Disconnected OpenAFS

[Simon Wilkinson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 23 Sep 2007, at 20:42, Matt Benjamin wrote:

> We have communicated privately about this, but I didn't think there  
> was
> anything secret in what I wrote, after having open discussion about  
> this
> with Simon at the openafs workshop;  I apologize, to you and Simon,  
> if I
> misunderstood that.

I don't think that its any great secret that I've been working away  
on this. Unfortunately, I haven't yet had as much free time as I  
would have liked to spend on it, but I'm happy to share my experience  
so far. I've been working on re-implementing disconnected support  
using the code on the 'disconnected' branch as a guide - the tree has  
changed sufficiently that simply porting this code across didn't seem  
like a viable option.

I've currently got a working read-only disconnected implementation  
going. This provides a disconnected machine with read-only access to  
items which are still held in the dcache. There are a number of  
issues with this

*) There's no serialisation to disk implemented. If the machine is  
rebooted all of the information in volatile memory (vcache, and other  
structures) is lost - and entries held in the dcache can no longer be  
accessed. The AFS 'vnode' has changed such that the serialisation  
code in the disconnected branch is no longer usable, in particular  
because it assumes that AFS, rather than the kernel, owns the vnode.
*) Data consistency is interesting. If a server breaks a callback, no  
attempt is made to update the clients cache. If the client  
subsequently goes disconnected, then that cached data will be made  
available to the client, regardless of how the data on the server  
changed. This is definitely sub-optimal. As Jeffrey mentions some UI  
is really needed here - a mechanism for 'pinning' files in the cache,  
and then code in the cache manager which will update the contents of  
pinned files when callback breaks are received for those files. We  
should probably not make files with callbacks that are broken at the  
time the client goes disconnected available, as we know that that  
data is definitely out of date.
*) Access control is hard. In the original code, a client going  
disconnected simply disables all access control checks in the cache  
manager. In my current implementation, we continue to perform access  
control, but this means you can only access your files whilst your  
tokens are valid. Once your tokens expire disconnected mode will no  
longer work. This is, obviously, an issue.
*) Locking is broken. My code will just approve all of the locks the  
client asks for when running in disconnected mode. It does nothing  
with these upon reconnection.
*) The 'disconnected' flag isn't lock protected. You _really_ don't  
want to go disconnected in the middle of a vnodeop, so some form of  
locking is required. Ideally when a 'go disconnected' request
is received you want to allow all currently running operations to  
complete, but block any new operations from starting.

My gut feeling is that once serialisation is done, it should be  
fairly straightforward to move the operation logging and replay code  
across from the disconnected branch to HEAD, but there's not much  
point in doing so until there's a disconnected mode that can work  
across client restarts.

Cheers,

Simon.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFG92ktqWndc26pXmcRArrSAJ4p+llM62ndIXYMdOq07S/5R9/uuQCgsFGN
rWZl8rj/f0joboA8kZw92Vg=
=11sE
-----END PGP SIGNATURE-----