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.
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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
