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

[Jeffrey Hutzelman]

On Mon, 3 Dec 2001, Nathan Neulinger wrote:

> Stage 2: Add support for block range locks to the file servers. 
> Added RPC: GetSmallestLockSize
> Added RPC: LockRange(... size ...)
> 
> This will build upon the support in stage 1. Basically, when the client
> receives a request for a byte range lock, before immediately upgrading
> it to a full-file lock, it should ask the server "what size locks do you
> support". If the server supports smaller locks than whole-file, then
> request the minimal lock needed.
> 
> NOTE - The minimum lock size requestable by the client should be no
> smaller than the minimum update-size sent to the server. (i.e. if the
> client sends a whole block to the server when the process updates a
> single byte, then it should request a lock no smaller than the block,
> regardless of what the server supports.)
> 
> This should still retain full support for all clients, other clients
> will continue to request full-file locks, which would be granted or not
> as usual. 
> 
> Gain: Better granularity, assuming just block locking, multiple clients
> could start doing byte-range locks, so long as they were in different
> blocks of the file.

Unfortunately, you're not only glossing over all the problems with having
the server keep lock state (most of which are not insurmountable); you're
also missing a fundamental problem.  If you allow multiple hosts to hold
byte-range locks at the same time, then applications on those hosts will
try to write the file at the same time.  The result will be a mess, since
the applications think they have locked the parts of the file they're
updating but the whole-file last-write semantics of AFS mean they really
don't.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA