[OpenAFS] Disconnected OpenAFS

Jeffrey Altman jaltman@secure-endpoints.com
Tue, 25 Sep 2007 09:09:02 -0400


Jim Rees wrote:
> Jeffrey Altman wrote:
> 
>   For each vnode in the cache, you keep track of the
>   connected/disconnected state.  While you are in the transition from
>   connected -> disconnected you sync files into the cache and mark them
>   disconnected.  When a request comes in for a file marked disconnected,
>   you treat it as if disconnected mode was active.
> 
> But that wouldn't guarantee the consistency that Simon wants.  If you have
> two files in your cache A and B, A is disconnected and B is not, then some
> other client writes both files, you will have the old copy of A and the new
> copy of B.  How is that any different from an implementation that does not
> obtain a callback on all files before disconnecting?

What are the use models for disconnected mode?

(1) Organization A that wants to deploy applications to desktops via
AFS.  The applications are deployed using .readonly volumes.  One
callback for the entire volume.  In this situation when the user
switches to disconnected mode, the entire contents of the volume will be
marked disconnected at once.   Everything will be in the cache and it
will all be consistent.

(2) User wants access to specific files or directories from r/w volumes.
Whether or not the client obtains perfect consistency is dependent upon
how many files/directories there are, how many file servers are
involved, and how many files are in each directory.  However, it is easy
enough to guarantee consistency of all the files in a given directory
with a bulk stat before and after the synchronization.

Is it absolutely perfect synchronization across the entire AFS file
system name space?  No.   It is localized synchronization.

Is there a chance that a user can still end up with a useless file?
Absolutely.  For example, what if a user synchronizes a file that is
currently in use by another user where the file has had partial writes
applied to the file.  I think the perfect example is a Microsoft Office
document.  The file was opened, modified, and then most of the data was
placed into a temp file until the application closes the file and stops
working on it.  Given the lack of proper lock semantics there is little
that can be done to protect against this.  Once we have mandatory locks
available the cache manager won't need 1000 callbacks, it will simply
need the ability to obtain read locks on all the files it wants to
synchronize in a given set.

Part of the responsibility of the disconnected UI is to provide the user
with the ability to specify what subsets of the AFS name space are
required for synchronization.  Selected items that are grouped together
can be obtained together as a set.  Those that are not grouped together
can be obtained separately.

The primary problem with the existing disconnected mode is that the
entire contents of the cache is offered for disconnected use whether or
not the cache manager has any idea how old the data is and whether or
not there is any chance that the data might still be valid.  Its simply
a question of what happens to be in the cache at any given time.

Jeffrey Altman