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

[Matt W. Benjamin]

----- 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).


> The rest of the volumeIds that are assigned are used for what I will
> categorize as maintenance or backup purposes.  In particular, they are
> used for snapshots which could be much better represented as the normal
> (rw) volumeId augmented by a 64-bit timestamp that has granularity finer
> than 1ms.  Assigning a new volumeId results in the problem that the
> volume group size must grow indefinitely to be able to support an
> arbitrary number of snapshots.  If we want to support arbitrary client
> accessible views of a volume at any point in time, the client should
> not need to figure out which of the thousands of random volumeIds is
> the readonly snapshot of volumeId 93738294 at "2009 January 3
> 17:43:23.228932".


_______________________________________________
AFS3-standardization mailing list
AFS3-standardization@openafs.org
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization