-----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-----
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
