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. > > 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. > Transliteration of objects is obviously possible, but this is a case of the payload needing to be specified and revisions proposed and standardized. > 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. > I'd argue it is possible to support old ubik servers, by translating a new database to old when the old RPCs are used, and changes here can be done with care by the implementation to support or explicitly disallow mixed-mode cells. The database must obviously not be destroyed, and a downgrade mechanism should be provided, but those are implementation details. -- Derrick
_______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
