[AFS3-std] [RPC Request] 64-bit volume IDs, quotas, and block
usages
Derrick Brashear
shadow@gmail.com
Mon, 22 Jun 2009 16:59:59 -0400
--00163616469137728f046cf62890
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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.
>
> 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
--00163616469137728f046cf62890
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br><div class=3D"gmail_quote">On Mon, Jun 22, 2009 at 4:50 PM, Jeffrey=
Hutzelman <span dir=3D"ltr"><<a href=3D"mailto:jhutz@cmu.edu">jhutz@cmu=
.edu</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"bo=
rder-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding=
-left: 1ex;">
<div class=3D"im">--On Friday, June 19, 2009 04:49:15 PM -0500 Andrew Deaso=
n <<a href=3D"mailto:adeason@sinenomine.net" target=3D"_blank">adeason@s=
inenomine.net</a>> wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Per suggestions from Jeffrey Altman and others, here are what I believe<br>
to be the requirements for 64-bit fields pertaining to volume IDs,<br>
volume quotas, and block usage on volumes/partitions.<br>
<br>
The format resembles what Jeffrey posted as an example earlier, but I<br>
separated the affected RPCs according to what underlying struct changed<br>
in the RPC (if any); I just found it easier to follow. This is what's i=
n<br>
the parentheses by "Affected RPCs". Some RPCs are listed more tha=
n once<br>
because of this: once for each structure changed. I also merged some<br>
fields into the same section when the list of affected RPCs was<br>
identical.<br>
</blockquote>
<br></div>
By concentrating only on RPC's, you are missing significant portions of=
the protocol. =A0Anyone considering or proposing a change like this also n=
eeds to consider its impacts on other parts of the protocol suite, includin=
g...<br>
<br>
1) The volume dump format, as represented in the data of RPC's like AFS=
VolDump and AFSVolRestore.<br>
</blockquote><div><br>As this is tagged, additional tags can be allocated, =
represented by capabilities, and tools (implementation-specific) can be pro=
vided to downgrade dumps if desired. <br></div><blockquote class=3D"gmail_q=
uote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0=
pt 0.8ex; padding-left: 1ex;">
<br>
2) The on-wire directory format, as represented in the data of RXAFS_FetchD=
ata on a directory. =A0This is presently the same as the on-disk format use=
d by the OpenAFS server, but there is no requirement that they be kept in s=
ync.<br>
</blockquote><div><br>Transliteration of objects is obviously possible, but=
this is a case of the payload needing to be specified and revisions propos=
ed and standardized. <br></div><br><blockquote class=3D"gmail_quote" style=
=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; p=
adding-left: 1ex;">
<br>
4) ubik database formats. =A0These are specific to the OpenAFS implementati=
on and are not the subject of standardization work, but there are similar i=
nteroperability considerations to work through, particularly regarding what=
happens when you have mixed-version dbservers and what happens when you up=
grade/downgrade. =A0It might be acceptable to require upgrading everything =
at once; it is not acceptable for breaking that rule to result in destroyin=
g the database.<br>
</blockquote><div><br>I'd argue it is possible to support old ubik serv=
ers, by translating a new database to old when the old RPCs are used, and c=
hanges here can be done with care by the implementation to support or expli=
citly disallow mixed-mode cells. The database must obviously not be destroy=
ed, and a downgrade mechanism should be provided, but those are implementat=
ion details.<br>
<br></div></div><br clear=3D"all"><br>-- <br>Derrick<br>
--00163616469137728f046cf62890--