[AFS3-std] [RPC Request] 64-bit volume IDs, quotas, and block usages

[Matt W. Benjamin]

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" <jaltman@secure-endpoints.com>
To: afs3-standardization@openafs.org
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
AFS3-standardization@openafs.org
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization