[AFS3-std] [RPC Request] 64-bit volume IDs, quotas, and block
usages
Derrick Brashear
shadow@gmail.com
Mon, 22 Jun 2009 00:28:48 -0400
--001485eafe8c7a4f6c046ce84fde
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
On Sun, Jun 21, 2009 at 10:35 AM, Jeffrey Altman <
jaltman@secure-endpoints.com> wrote:
> Matt W. Benjamin wrote:
> > ----- Original Message -----
> > From: "Jeffrey Altman" <jaltman@secure-endpoints.com>
> >
> > I agree that the proposal to increase the volume id space should be
> motivated, but the motivation is that we wish to be able to provide logical
> support for very large numbers of volumes, even presuming a site that is,
> for reasons of its own, creating new volumes at a rate difficult for us the
> designers to grasp. Specifically, a site creating one volume per second
> could begin using AFS today, and exhaust a 31-bit volume id space in 68
> years. I think that's not comfortably near countable infinity, and that's
> not counting the additional volume ids consumed by replicas.
> I really wish you would have spoken to the issue of backward
> compatibility. Increasing the volumeId space is desirable; but at what
> cost? There are organizations that use AFS that have machines that rely
> on AFS that cannot and will not ever have the software on those devices
> be altered. In federated deployments, the organizations that deploy the
> servers do not control the clients. It is never safe for them to
> upgrade to a new server version if it will break compatibility with the
> existing deployments.
>
> When I speak with CIOs of organizations about why they are considering
> alternatives to AFS, one of the primary concerns is that they do not
> have faith that AFS will continue to be able to support the new clients
> that will be available ten years from now. The primary barrier to
> switching is that the alternatives do not support all of the platforms
> they already have deployed over the last ten years.
>
> Replacing RPCs and adding new functionality is fine but doing so in a
> manner that breaks backward compatibility is a sure fire method of
> killing off AFS. We do not have the luxary of turning off support for
> the existing RPCs. As a result, any attempt to introduce a 64-bit
> volumeId is going to have to provide a method for communicating that
> 64-bit value to clients that only understand 32-bit volumeIds.
> I do not see the 32-bit volumeId space as a barrier. The limitation is
> more than a billion volume groups per cell and there is no limitation to
> the number of cells that an organization can deploy. If the best
> argument in favor of the change is that in 68 years we are going to have
> a problem then I do not see a reason why such a change needs to be
> implemented now.
>
1 per second adding up to 68 years is not "in 68 years"
Backwards compatibility should not be a barrier to deploying new RPCs. It
should be a barrier to allowing the addition space to be used in
environments which do not wish to break said compatibility. The least common
denominator should not be allowed to hold back sites wanting or needing
more.
For sites that cannot change clients, disallowing consumption of IDs beyond
the current limit is an easy answer. If I want to use more, and am willing
to, for my site, do the upgrades or make some volumes unusable to old
clients, I don't see why I should be restrained from doing so.
--
Derrick
--001485eafe8c7a4f6c046ce84fde
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br><div class=3D"gmail_quote">On Sun, Jun 21, 2009 at 10:35 AM, Jeffre=
y Altman <span dir=3D"ltr"><<a href=3D"mailto:jaltman@secure-endpoints.c=
om">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">Matt W. Benjamin wrote:<br>
> ----- Original Message -----<br>
> From: "Jeffrey Altman" <<a href=3D"mailto:jaltman@secure-=
endpoints.com">jaltman@secure-endpoints.com</a>><br>
><br>
> I agree that the proposal to increase the volume id space should be mo=
tivated, but the motivation is that we wish to be able to provide logical s=
upport for very large numbers of volumes, even presuming a site that is, fo=
r reasons of its own, creating new volumes at a rate difficult for us the d=
esigners to grasp. =A0Specifically, a site creating one volume per second c=
ould begin using AFS today, and exhaust a 31-bit volume id space in 68 year=
s. =A0I think that's not comfortably near countable infinity, and that&=
#39;s not counting the additional volume ids consumed by replicas.<br>
</div>I really wish you would have spoken to the issue of backward<br>
compatibility. =A0Increasing the volumeId space is desirable; but at what<b=
r>
cost? =A0There are organizations that use AFS that have machines that rely<=
br>
on AFS that cannot and will not ever have the software on those devices<br>
be altered. =A0In federated deployments, the organizations that deploy the<=
br>
servers do not control the clients. =A0It is never safe for them to<br>
upgrade to a new server version if it will break compatibility with the<br>
existing deployments.<br>
<br>
When I speak with CIOs of organizations about why they are considering<br>
alternatives to AFS, one of the primary concerns is that they do not<br>
have faith that AFS will continue to be able to support the new clients<br>
that will be available ten years from now. =A0The primary barrier to<br>
switching is that the alternatives do not support all of the platforms<br>
they already have deployed over the last ten years.<br>
<br>
Replacing RPCs and adding new functionality is fine but doing so in a<br>
manner that breaks backward compatibility is a sure fire method of<br>
killing off AFS. =A0We do not have the luxary of turning off support for<br=
>
the existing RPCs. =A0As a result, any attempt to introduce a 64-bit<br>
volumeId is going to have to provide a method for communicating that<br>
64-bit value to clients that only understand 32-bit volumeIds.<br>
I do not see the 32-bit volumeId space as a barrier. =A0The limitation is<b=
r>
more than a billion volume groups per cell and there is no limitation to<br=
>
the number of cells that an organization can deploy. =A0If the best<br>
argument in favor of the change is that in 68 years we are going to have<br=
>
a problem then I do not see a reason why such a change needs to be<br>
implemented now.<br>
<font color=3D"#888888"></font></blockquote><div><br>1 per second adding up=
to 68 years is not "in 68 years"<br>=A0<br>Backwards compatibili=
ty should not be a barrier to deploying new RPCs. It should be a barrier to=
allowing the addition space to be used in environments which do not wish t=
o break said compatibility. The least common denominator should not be allo=
wed to hold back sites wanting or needing more.<br>
<br>For sites that cannot change clients, disallowing consumption of IDs be=
yond the current limit is an easy answer. If I want to use more, and am wil=
ling to, for my site, do the upgrades or make some volumes unusable to old =
clients, I don't see why I should be restrained from doing so.<br>
</div></div><br>-- <br>Derrick<br>
--001485eafe8c7a4f6c046ce84fde--