[AFS3-std] Proposal: Extension of RXAFS_SetLock to support LockUpgrade and LockDowngrade

[Jeffrey Hutzelman]

On Mon, 27 Feb 2006, Jeffrey Altman wrote:

> A capability bit is a positive indication that functionality exists.
> Cached state is a negative indication.  When caching positive
> information the client will notice if the availability of functionality
> changes because the call to the function will fail in addition to the
> state of the capability bit being altered the next time the server is
> probed.
>
> When caching negative state the client will not know to test the
> the server again to determine if the functionality is supported.

I'll buy this argument, at least in some cases.  However, I think we need
to make it clear that a server MUST NOT change its capability
advertisements except across a restart; that is, an event in which it
throws away all callbacks, lock state, rx connections, and state related
to client identities and callbacks.  The same goes for the set of RPC's a
server supports, which is essentially a special type of capability (hm).

Given this requirement, a server that starts to support lock upgrades can
do so only across a restart, in which case it has forgotten the lock
anyway.  So, there is no harm in releasing the lock you don't have anyway,
rather than trying an upgrade.  In fact, across a restart, you're going to
_have_ to acquire a new lock, since you've lost the one you had.

> Another argument:
>
> Capability bits are cheap.  They take up just as much memory in the
> client to cache as the flags to maintain lack of functionality of the
> server.  The logic associated with maintaining Capability state is
> simpler than that of maintaining negative state.

Capability bits are cheap as long as we don't have very many.
When we start to get large numbers of them, carrying them all may become
expensive.


That said, I don't feel very strongly about this particular case.
I'm more concerned about the precedent of creating capability bits at the
drop of a hat.

-- Jeff