--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.
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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
