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