[AFS3-std] File Server/Cache Manager Extended Status Information

[Jeffrey Hutzelman]

Actually, it may turn out that the improvement you get is the other way around.  The file may change several times while someone else continues to hold the lock.

-----Original Message-----
From: Jeffrey Altman <jaltman@secure-endpoints.com>
Date: Monday, Apr 7, 2008 8:06 pm
Subject: Re: [AFS3-std] File Server/Cache Manager Extended Status Information
To: jhutz@cmu.edu
CC: matt@linuxbox.com, afs3-standardization@openafs.orgReply-To: jaltman@secure-endpoints.com

Jeffrey Hutzelman wrote:
> --On Monday, April 07, 2008 04:18:49 PM -0400 Jeffrey Altman 
> <jaltman@secure-endpoints.com> wrote:
>
>>> As opposed to the existing model in which
>>
>>    1. client A requests block byte range write lock on fid 1.2.3
>>    2. server replies EWOULDBLOCK
>>    3. another client drops the held lock
>>    4. server sends client A a callback indicating that the lock state on
>>       fid 1.2.3 has changed
>>    5. client decides whether or not to request the lock again.  if so,
>>       go to 1
>
>> Actually, last I checked (about 3 seconds ago) the existing model is 
> that after the server replies EWOULDBLOCK, client A sleeps for 1 
> second and tries again.  What you describe would be a significant 
> improvement, and requires only that the clients change, since 
> RXAFS_LockRelease has done a callback on release of the last lock for 
> some time.
>The UNIX cache manager retries in 1 second because no effort has been done to optimize it. 
>The Windows cache manager has a much more sophisticated lock allocation and request tracking model that would immediately make use of a informative callback notification that the lock has been dropped.  Now the callback notification must clear the status info as well as the lock state so the overhead is a bit too high to use for locking requests.  
>The real savings will come from being able to preserve the status info for a lock notification (provided that we specify that the lock drop notification does not clear the callback registration.)
>
>
>
>