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

[Jeffrey Hutzelman]

--On Monday, June 22, 2009 04:59:59 PM -0400 Derrick Brashear 
<shadow@gmail.com> wrote:

> On Mon, Jun 22, 2009 at 4:50 PM, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
>
>> --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.
>>
>
> As this is tagged, additional tags can be allocated, represented by
> capabilities, and tools (implementation-specific) can be provided to
> downgrade dumps if desired.

New tags can be allocated, but it's not as simple as just saying "allocate 
a new tag".  It's necessary to enumerate the changes that will need to be 
made and how they'll interoperate with old clients.  Note also that while 
there are some cases where capabilities will help you, in general a 
volserver generating a dump has no way to know what are the capabilities of 
the eventual recipient of that dump, and a client sending a dump to 
AFSVolRestore can tell what the receiving server's capabilities are but 
usually has no way to adapt the dump to them.

Volume dumps can include both critical and non-critical tag extensions, and 
the size and limited type information for non-critical tags can be 
determined even by parsers which do not understand the tag.  However, even 
with non-critical tags, restoring a new dump to an old server may throw 
away information.

In the particular case of 64-bit volume ID's, an extension can and should 
use the existing format with 32-bit ID's, plus a non-critical extension tag 
to represent the real 64-bit volume ID when that does not fit in 32 bits. 
Since volume ID's in dumps are largely transient, this does not throw away 
any important information.  The same approach may not be feasible for the 
next extension.

The point is, this is part of the protocol suite and needs to be considered 
when proposing an extension, just as RPC arguments do.