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

Jason Edgecombe jason@rampaginggeek.com
Sat, 20 Jun 2009 13:40:07 -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.
>
> Providing a separate space for snapshot identifiers is a good idea.  I don't intuitively see the motivation for making it a timestamp, however.  Every snapshot surely will a creation time, but it might have other attributes a client would want to use to identify it.  More importantly, even assuming continuous, point-in-time snapshots (every time something changes), the mapping of timestamps to snapshots at the suggested resolution is very sparse.  My suggestion for snapshot identifiers would simply be a generation number, and I'd hope to see follow-on discussion about how database servers (or external databases) should best be used to identify snapshots, using what criteria (most recent, earliest before a given time, the one associated with a specific tag, or whatever).
>
>   
would the proposal allow for clones of the same snapshot to reside on 
multiple servers?

Jason