[AFS3-std] [RPC Request] 64-bit volume IDs, quotas, and block
usages
Jeffrey Altman
jaltman@secure-endpoints.com
Sun, 21 Jun 2009 10:35:25 -0400
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.
Jeffrey Altman