[AFS3-std] Standardization of GetCapabilties RPCs for AFS3 client and services

[Jeffrey Altman]

Jeffrey Hutzelman wrote:

> Before I can make any more substantive comments on this issue, I need to
> try to understand the problem Jeff is actually trying to solve.  It
> would be very helpful if he and/or you could explain what scenario you
> are trying to solve, and why this is the right way to solve it.  It
> would also help if you would just explain your position, instead of
> making oblique references to unrelated issues and expecting us to guess
> what analogy you're trying to draw.
> 
> -- Jeff

Jeff:

Please re-read the openafs-info thread from 12-01-2005 started by Terry
McCoy entitled "1.4.1-rc2 build question".  What I took away from that
thread was a desire by cell administrators including yourself to prevent
Windows AFS clients contacting your servers from obtaining AFS File
Locks in order to prevent increases in server load and to avoid
potential support issues caused by the fact that not all of your volumes
used by the Windows clients have 'k' privileges.

When 1.6 ships the Windows clients are going to stop being broken with
regards to locks.  If the Windows CIFS client asks for a lock, the AFS
Cache Manager is going to request that lock.  This scares many
administrators and they would prefer the existing behavior in which the
Windows Cache Manager never requests an AFS File Lock unless the
requested lock starts at offset 0 and the length of the locking range is
greater than or equal to the file size.  These administrators want a
means to control when the new behaviors kick in while at the same time
having their users benefit from new user interfaces, support for 64-bit
Windows platforms, and performance improvements.

As you have pointed out many times, the administrators do not control
the version of the client in use.  Users download and install the latest
client for a number of reasons.  They may have experienced a crash and
sent a report to Microsoft.  I receive the crash reports and when the
crash is fixed in a later build I register a response with that crash
instructing the user that the bug is fixed and pointing them to the
openafs.org web site.   They may subscribe to openafs-announce and
download new versions as they are released.   They may get their version
of OpenAFS from another organization.  Or their machines may be managed
by someone else.  Whatever the reason, the administrator of the servers
has no control over the client but still does not want the clients
behavior to change.

The only way that I know of that can be used to accommodate the needs of
the administrators is to allow the servers to provide hints to the
clients.  If you have an alternate proposal that will work, please
describe it.

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/20060226/c87e0527/smime.bin