On Mon, Jun 22, 2009 at 11:14 AM, Andrew Deason <[email protected]>wrote:
> On Mon, 22 Jun 2009 00:28:48 -0400 > Derrick Brashear <[email protected]> wrote: > > > Backwards compatibility should not be a barrier to deploying new > > RPCs. It should be a barrier to allowing the addition space to be > > used in environments which do not wish to break said compatibility. > > The least common denominator should not be allowed to hold back sites > > wanting or needing more. > > > > For sites that cannot change clients, disallowing consumption of IDs > > beyond the current limit is an easy answer. If I want to use more, > > and am willing to, for my site, do the upgrades or make some volumes > > unusable to old clients, I don't see why I should be restrained from > > doing so. > > This was my intention when submitting this. I did not have a plan or > scheme in mind for backwards compatibility; if a site wants to support > legacy clients, I imagined they would simply not use volume IDs above > the 32-bit barrier. Implementations would/should have some kind of > administrative switch that administrators would explicitly have to turn > on to enable them. > > I'd also like to note that the simple 32->64 conversion isn't the only > way to do this. I've been told there's at least one other proposal in > the works for extending the volume ID-space which conflicts with what I > wrote. I'll see if I can help get it on this list soon. > If said proposal is only useful for snapshots (additional volumes in a group, with timestamp differentiation, or that ilk, which I've proposed before) it doesn't solve the issue of people legitimately needing more than 2^32 volumes. -- Derrick
_______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
