[AFS3-std] [RPC Request] 64-bit volume IDs, quotas, and block
usages
Derrick Brashear
shadow@gmail.com
Mon, 22 Jun 2009 09:34:12 -0400
--0016e6476e76ffd939046cefed24
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
On Mon, Jun 22, 2009 at 9:08 AM, Jeffrey Altman <
jaltman@secure-endpoints.com> wrote:
> Simon Wilkinson wrote:
> > I think we should remember our reasons for separating out
> > standardisation from OpenAFS. Whilst OpenAFS's concerns (as the major
> > implementor) can certainly guide our discussions, I don't think what
> > the gatekeepers feel they can or cannot implement should necessarily
> > constrain those discussions.
> Agreed. The point that I'm trying to drive home is that consideration
> of the backward compatibility issues is important and that the
> transition from one set of RPCs to the other is equally important to
> many impacted by these changes. Future looking features should be
> designed into the protocol.
>
> The corollary of Simon's statement is equally true. Just because
> something gets into the protocol does not mean it will be implemented
> within OpenAFS.
> >
> > So, I think there are two real issues here:
> >
> > a) Is it desirable that a future version of the AFS protocol be
> > capable of supporting 64 bit volume IDs?
> I believe the answer is 'yes'.
> > b) Given a) do we want to include 64 bit volume IDs in the protocol
> > revision we are currently discussing?
> I believe the answer is 'maybe' leaning towards 'yes'.
>
If it is done (I think it should be) then recommendations to implementors to
ease backwards compatibility should be provided in the extension
document; Among those, from gatekeeper discussion notes, would be the
suggestion to provide mappings or policy engine to allow volumes which older
clients need to be placed within 32 bit space, and allocating temporary
clone IDs outside the 32 bit space.
--0016e6476e76ffd939046cefed24
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 9:08 AM, Jeffrey=
Altman <span dir=3D"ltr"><<a href=3D"mailto:jaltman@secure-endpoints.co=
m">jaltman@secure-endpoints.com</a>></span> wrote:<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;">
<div class=3D"im">Simon Wilkinson wrote:<br>
> I think we should remember our reasons for separating out<br>
> standardisation from OpenAFS. Whilst OpenAFS's concerns (as the ma=
jor<br>
> implementor) can certainly guide our discussions, I don't think wh=
at<br>
> the gatekeepers feel they can or cannot implement should necessarily<b=
r>
> constrain those discussions.<br>
</div>Agreed. =A0The point that I'm trying to drive home is that consid=
eration<br>
of the backward compatibility issues is important and that the<br>
transition from one set of RPCs to the other is equally important to<br>
many impacted by these changes. =A0Future looking features should be<br>
designed into the protocol.<br>
<br>
The corollary of Simon's statement is equally true. =A0Just because<br>
something gets into the protocol does not mean it will be implemented<br>
within OpenAFS.<br>
<div class=3D"im">><br>
> So, I think there are two real issues here:<br>
><br>
> a) Is it desirable that a future version of the AFS protocol be<br>
> capable of supporting 64 bit volume IDs?<br>
</div>I believe the answer is 'yes'.<br>
<div class=3D"im">> b) Given a) do we want to include 64 bit volume IDs =
in the protocol<br>
> revision we are currently discussing?<br>
</div>I believe the answer is 'maybe' leaning towards 'yes'=
.<br>
</blockquote><div><br>If it is done (I think it should be) then recommendat=
ions to implementors to ease backwards compatibility should be provided in =
the extension<br>document; Among those, from gatekeeper discussion notes, w=
ould be the suggestion to provide mappings or policy engine to allow volume=
s which older clients need to be placed within 32 bit space, and allocating=
temporary clone IDs outside the 32 bit space.<br>
<br></div></div><br>
--0016e6476e76ffd939046cefed24--