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

[Jeffrey Altman]

Jeffrey Hutzelman wrote:
> On Sun, 26 Feb 2006, Jeffrey Altman wrote:
> 
>> For the reason I explained above.  Capability bits are cheap.  Try and
>> fallback is expensive.  Its not safe to cache the knowledge gained by
>> trying and failing.
> 
> ... because?

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.

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.

Jeffrey Altman


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