[AFS3-std] [RPC Request] 64-bit volume IDs, quotas, and block usages

[Jeffrey Altman]

Simon Wilkinson wrote:
> I think we should remember our reasons for separating out
> standardisation from OpenAFS. Whilst OpenAFS's concerns (as the major
> implementor) can certainly guide our discussions, I don't think what
> the gatekeepers feel they can or cannot implement should necessarily
> constrain those discussions.
Agreed.  The point that I'm trying to drive home is that consideration
of the backward compatibility issues is important and that the
transition from one set of RPCs to the other is equally important to
many impacted by these changes.  Future looking features should be
designed into the protocol. 

The corollary of Simon's statement is equally true.  Just because
something gets into the protocol does not mean it will be implemented
within OpenAFS.
>
> So, I think there are two real issues here:
>
> a) Is it desirable that a future version of the AFS protocol be
> capable of supporting 64 bit volume IDs?
I believe the answer is 'yes'.
> b) Given a) do we want to include 64 bit volume IDs in the protocol
> revision we are currently discussing?
I believe the answer is 'maybe' leaning towards 'yes'. 

I suspect there are more transition issues that will need to be
identified.   In the meantime, one more implementation note for this
extension:

   1. One of the following must be true:
         1. Any client or server that implements the new RPC must be
            prepared to accept an extended volumeId and must not assume
            that there will not be any simply because there have not
            been in the past.  This includes faking an error response
            equivalent to the server's required behavior when the old
            RPC is used.
         2. Capability bits indicating the support for 64-bit volumeIds
            will need to be allocated for each entity that receives
            volumeIds.

Jeffrey Altman