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

[Jeffrey Hutzelman]

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


> Using multiple callback messages would make it hard to coalesce delayed
> callbacks of different types.

Yes, but it might not matter.  For one thing, I'm not sure we need to 
provide extended notifications from BreakDelayedCallbacks; it may be 
sufficient just to do a traditional callback break and let the client sort 
it out, at least initially.

Incidentally, I don't think "union is not currently used" is a good 
argument for not using it.  I'm pretty sure I've actually seen a use 
outside of AFS, though I can't find it at the moment, but even if there is 
none, it doesn't matter.  If it turns out to be buggy, we'll fix it!

-- Jeff