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

[Nathan Neulinger]

Leif Johansson and I were discussing some possible ways of implementing
this during LISA that should be relatively easy to implement (I think)
at the client side and server.

Here's the idea:

Stage 1: Upgradable byte range locks at the client side
(Client change only, assumes existing servers only)

When a process on client requests a byte range lock, first attempt to
get a full file lock on the server (if one has not already been obtained
by this local client). If successful, locally attempt to grant the byte
range lock.

Gain: This allows multiple processes on a single host to use byte range
locks locally, which will help multi-process apps work properly when
components of the same app need to lock for synchronization within
itself. 


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.




This was just some discussion on how this could be done in a reasonable
fashion. I'm not sure if there are other considerations that would make
the above impossible/etc, but it seems like it should be relatively easy
to implement.


-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216