--On Monday, June 22, 2009 04:59:59 PM -0400 Derrick Brashear
<[email protected]> wrote:
On Mon, Jun 22, 2009 at 4:50 PM, Jeffrey Hutzelman <[email protected]> wrote:
--On Friday, June 19, 2009 04:49:15 PM -0500 Andrew Deason <
[email protected]> 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.
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
