My point was that a namespace of a billion volumes clearly is too small, in the sense that neither of us would suggest it if we were designing the protocol today. So it's right for us to give serious consideration to expanding the namespace, and to making backward compatibility with the oldest clients a secondary consideration. The notion that by modernizing AFS we accelerate its replacement in legacy deployments is credible, but, at the same time, we clearly must modernize to keep another group of users, and bring new ones--I'm sure you hear this from folks all the time, too, I know I do. I guess this needs further discussion.
----- Original Message ----- From: "Jeffrey Altman" <[email protected]> To: [email protected] Sent: Sunday, June 21, 2009 10:35:25 AM GMT -05:00 US/Canada Eastern Subject: Re: [AFS3-std] [RPC Request] 64-bit volume IDs, quotas, and block usages 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 _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
