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

[Jeffrey Hutzelman]

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.
> 
> 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
> 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.
> 
> Because the token protocol touches everything ; I doubt it would be
> possible to make DFS work in disconnected mode operation.
> 
> There is a white paper on the DFS token protocol out there - I belive it
> was among the DCE 1.2.2 documentation tar ball.  I havent touched DCE
> stuff in years though ; and dont intend to ever again. :)

As Jim points out, the DFS token mechanism affects both performance and
memory footprints, as well as makeing crash recovery take longer.  It also
has some unfortunate security effects -- in order to avoid excessive
performance problems and some other nasty protocol problems, the DFS token
protocol is completely unauthenticated.  This means that any client can
acquire a lock on absolutely anything at all, and keep that lock for as
long as the server will let it (IIRC, that means forever, unless an
administrator intervenes).

-- Jeff