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 <[EMAIL PROTECTED]> Date: Monday, Apr 7, 2008 8:06 pm Subject: Re: [AFS3-std] File Server/Cache Manager Extended Status Information To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED]: [EMAIL PROTECTED] Jeffrey Hutzelman wrote: > --On Monday, April 07, 2008 04:18:49 PM -0400 Jeffrey Altman > <[EMAIL PROTECTED]> 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.) > > > > _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
