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

[Jeffrey Altman]

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.)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://michigan-openafs-lists.central.org/archives/afs3-standardization/attachments/20080407/bead7123/smime-0001.bin