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

[Andrew Deason]

On Mon, 22 Jun 2009 00:28:48 -0400
Derrick Brashear <shadow@gmail.com> 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.

-- 
Andrew Deason
adeason@sinenomine.net