[OpenAFS-devel] afs and byte-range locking ideas

[Craig_Everhart@transarc.com]

We might have to agree to disagree, but I'll say my two cents.

Excerpts from transarc.external.openafs: 5-Dec-01 Re: [OpenAFS-devel]
afs and.. Jeffrey Hutzelman@cmu.ed (2343*)

> On Wed, 5 Dec 2001, Jim Doyle wrote:

> > > Does DFS take a huge performance hit due to its support of byte-level
> > > locking?
> > 
> > Yes, there are a number of issues that come up with DCE/DFS.
> > 
> > There is a token protocol between the fileserver and cache manager that
> > provides for exclusive rights, synchronized read-writes, etc.  The token
> > meta-data is stored in memory in the fileserver instance and the
> > cache-mgr instance.  DFS fileservers could possibly require very large
> > memory footprints in a big cell with frequent concurrent R/W access to
> > files.

Tokens are recycled more aggressively (revoked, given shorter lifetimes)
when lots are in play, just as with AFS callbacks.  However, this
doesn't imply a "huge performance impact".

> > Another phenomenon with DFS is that when a file server crashes and
> > restarts, there is a "blackout" period in fileservice for some configured
> > period of time ; usually 15 minutes..  This period is called token state

The out-of-the-box default is three minutes.

> > recovery.  During TSR, the file server sits and waits for cache managers
> > who had prior been issues tokens to file to contact it to renew their
> > tokens... This is how the fileserver rebuilds its list of clients locks
> > after crash, and re-estabilishes the precedence on granting range order
> > access to files... If a cache mgr is unable to reach the file server
> > following the crash (i.e. network outage) - that cache manager simply
> > becomes S.O.L. and simply loses whatever rights it held on access locks.

Yes, this is a multiple failure (server crash plus subsequent network
outage).  This is a way for other active clients to continue to get work
done within the connected set.

In AFS the same outage happens.  Is this a huge performance hit?

> > Because the token protocol touches everything ; I doubt it would be
> > possible to make DFS work in disconnected mode operation.

Actually, DFS tokens make it possible for a hypothetical disconnected
client to know exactly what commitments it has, or doesn't have, from
the server, so that it could in principle be just as optimistic as any
of the disconnected-AFS clients that have been done.  The existing DFS
clients are known to be conservative in how they implement the
commitments they make to applications, but that's not the only way they
could be done.

		Craig