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

[Jeffrey Hutzelman]

--On Friday, June 19, 2009 04:49:15 PM -0500 Andrew Deason 
<adeason@sinenomine.net> wrote:

> Per suggestions from Jeffrey Altman and others, here are what I believe
> to be the requirements for 64-bit fields pertaining to volume IDs,
> volume quotas, and block usage on volumes/partitions.
>
> The format resembles what Jeffrey posted as an example earlier, but I
> separated the affected RPCs according to what underlying struct changed
> in the RPC (if any); I just found it easier to follow. This is what's in
> the parentheses by "Affected RPCs". Some RPCs are listed more than once
> because of this: once for each structure changed. I also merged some
> fields into the same section when the list of affected RPCs was
> identical.

By concentrating only on RPC's, you are missing significant portions of the 
protocol.  Anyone considering or proposing a change like this also needs to 
consider its impacts on other parts of the protocol suite, including...

1) The volume dump format, as represented in the data of RPC's like 
AFSVolDump and AFSVolRestore.

2) The on-wire directory format, as represented in the data of 
RXAFS_FetchData on a directory.  This is presently the same as the on-disk 
format used by the OpenAFS server, but there is no requirement that they be 
kept in sync.

3) pioctl interfaces.  Even though these don't appear on the network, they 
do represent a protocol between cache managers and applications, with 
multiple implementations on both sides of the interface, registrar-managed 
number spaces, and an active effort to keep things interoperable.

4) ubik database formats.  These are specific to the OpenAFS implementation 
and are not the subject of standardization work, but there are similar 
interoperability considerations to work through, particularly regarding 
what happens when you have mixed-version dbservers and what happens when 
you upgrade/downgrade.  It might be acceptable to require upgrading 
everything at once; it is not acceptable for breaking that rule to result 
in destroying the database.

-- Jeff