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

[Steve Simmons]

On Jun 22, 2009, at 12:27 AM, Jeffrey Altman wrote:

> Increasing the volumeId field size to 64-bits is fine provided that  
> the
> transition model for older clients is documented and well understood.
> If the need of the community is that we support the older RPCs for a
> minimum of ten years from the time the last client ships with just the
> older RPCs, then rolling out RPCs that require new clients to be  
> able to
> handle 64-bit time and volumeIds this year will provide the  
> community 29
> years to upgrade software or retire old clients before the existing  
> RPCs
> will simply fail.

Pardon the lateness of my $0.02, but I think the above is the key  
point. It's not impossible to have some future smart cell that maps  
volume ids between 64 and 32 bit volids.  When it receives a 32-bit  
request, it maps the 32-bit volid to the 64, then serves the data  
based on the mapped volid. As long as the cell has less than 2^32  
volumes total, everything is fine. Should a 64-bit client happen to  
contact a 32-bit cell, well, it has to fall back to 32-bit RPCs.

Neither of these is acceptable on a permanent basis, but it does get  
things through the transition period to 64bit stuff. We can further  
push the transition if we tie the use of the hybrid clients to major  
releases of the client OS. A hybrid client and server might be ready  
by the time of deploying Window8 or 9, of some major OSX future, and  
some particular future Linux kernel. Once all three have become 99%+  
of the deployed systems, we can start looking at pulling out the 32- 
bit support.

In a similar manner, we need to think more about how to get backwards  
compatibility with longer volume names. A cell that starts approaching  
2^32 volumes is going to have real problems coming up with sensible  
volume names.

Someone made a comment about NASA running legacy systems that are 20- 
odd years old. That's true, but largely irrelevant - they're not  
putting those systems (with all their security issues) onto the global  
internet. On private networks, they can run old servers to serve their  
old clients.

Dan Hyde and I have had extensive discussions of some of the issues  
relating to having many many clones/shadows/snapshots of a given  
volume. It seems perfectly reasonable to me that there are some highly  
desirable features there, but they'd cause huge proliferation of  
volume IDs. Umich, like a lot of other sites, is about halfway to the  
max volid. At some point, afs will implement features that consume  
those IDs like popcorn. It would be very useful to have 64bit-ready  
clients out there sooner rather than later.