Jeffrey Hutzelman wrote:
--On Monday, April 07, 2008 04:18:49 PM -0400 Jeffrey Altman <[EMAIL PROTECTED]> wrote: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.)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 1Actually, 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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
