Re: New client-side locking implementation

Asanka's first cut at byte range locking for the OpenAFS Windows client
has been committed to the CVS HEAD.

http://www.openafs.org/cgi-bin/wdelta/MAIN/windows-byte-range-locks-20050816

Installers built off the head containing this code can be found at

   /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/Head/
   \\afs\athena.mit.edu\user\j\a\jaltman\Public\OpenAFS\Head\
   http://web.mit.edu/jaltman/Public/OpenAFS/Head/

The more conservative approach of not allowing reads/writes to the file
at all when locks have been lost is being enforced.

There is one outstanding issue related to lock promotion and demotion.
The AFS Lock RPCs currently only support three operations:

	* Obtain Lock
	* Extend Lock
	* Release Lock

The file server does not keep track of who owns a lock nor does it care
who extends a lock.   In fact, an evil client really could play havoc
with locks by releasing a lock it obtains multiple times.  (a topic for
another day.)   Unfortunately, there is no RPC for promote or demote.
This means that we have three possible choices we can make with the
existing RPCs:

(1) do not support lock promotion / demotion

(2) support p/d by releasing one lock and obtaining the other which
    opens a door to a race condition

(3) support p/d by always obtaining Write locks and enforcing the
    difference between Read locks and Write locks locally the same
    way we enforce the byte-range locks.

Currently the Unix client does (2).

Long term I would like to see a new version of SRXAFS_SetLock be
implemented that provides support for lock promotion / demotion.
The HandleLocks() src/viced/afsfileprocs.c function would simply
be modified to handle:

  LockPromote:
      if (lock count == 1)
	  lock count = -1;	
      else
	  return EINVAL;
      break;
  LockDemote:
      if (lock count == -1)
           lock count = 1;
      else
          return EINVAL;
      break;

The OldSetLock RPC would be renamed Old2SetLock and SetLock would be
renamed OldSetLock.

The client would then try to use the new RPC first and fall back to
the current form if it were not present.   When the new RPC is not
present, promotion / demotion would be implemented by releasing and
obtaining.

Thoughts?

begin:vcard
fn:Jeffrey Altman
n:Altman;Jeffrey
org:Secure Endpoints Inc.
adr:;;255 W 94TH ST PHB;NEW YORK;NY;10025;United States
email;internet:[email protected]
title:President
tel;work:+1 212 769-9018
x-mozilla-html:TRUE
url:http://www.secure-endpoints.com
version:2.1
end:vcard