Matt W. Benjamin wrote: > ----- Original Message ----- > From: "Jeffrey Altman" <[email protected]> > > 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 _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
