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

[Jeffrey Altman]

Matt W. Benjamin wrote:
> My point was that a namespace of a billion volumes clearly is too small, in the sense that neither of us would suggest it if we were designing the protocol today.  
We aren't designing a protocol from scratch.
> So it's right for us to give serious consideration to expanding the namespace, and to making backward compatibility with the oldest clients a secondary consideration.  
This is where you and the OpenAFS gatekeepers differ in a most
significant way.  For us backward compatibility is not a secondary
consideration.  It is the primary consideration.  The fact that we
OpenAFS works with all of the old Transarc clients and that we have not
had any significant transition issues for the users of Transarc AFS is a
point of significant pride.  If you do not maintain backward
compatibility then you might as well create a new file system from
scratch and start over with something that only meets the needs of the
future users.  If that is what you believe then you can go off and do
that on your own.  Steal the portions of AFS3 that you wish, come up
with a name for your new protocol or get ready to be sued by IBM for a
trademark violation.
> The notion that by modernizing AFS we accelerate its replacement in legacy deployments is credible, but, at the same time, we clearly must modernize to keep another group of users, and bring new ones--I'm sure you hear this from folks all the time, too, I know I do.  I guess this needs further discussion.
The users I speak with put their wishes into the following priorities:

   1. robustness and stability.  this is why the vast majority of the
      work on OpenAFS over the last three years has not been new
      features.  Its hard to focus on features or marketing the product
      to new users when you spend all of your time fighting fires.
   2. first class support for existing client operating system
      functionality.  for MacOS X and Windows: integration with the
      graphical user interface.  Support for Unicode.  Support for byte
      range locking on the file servers.  Support for extended
      attributes.  Support for multiple data streams.  Support for any
      native file system functionality for which the lack of support
      results in the end user recognizing that there is something
      special about keeping their data in AFS vs other first class file
      systems as recognized by the OS vendor.  For Linux, either kAFS
      instead of OpenAFS or Fuse AFS because the kernel licensing
      conflicts result in too much fear, uncertainty and doubt about the
      future stability of the file system.
   3. read write replication!!!  Primarily for use as a light weight
      fail over system. 
   4. performance.  increased directory sizes.  increased network
      bandwidth.  decreased directory lookup times.
   5. better management tools.  improved ease of use for initial
      deployment and on-going administration.
   6. NAT and Firewall compatibility.  TCP based transports.  Removing
      fixed port dependencies.  Removing IP addresses from protocol
      exchanges so that split horizon DNS deployments will work.
   7. Search capabilities.  Integration with desktop search so that
      users can find things within the file system. 
   8. Security.  Alternative authentication methods and stronger data
      privacy protection but not at the cost of performance.  Security
      policies that permit encryption to be required only on the volumes
      where it matters.   If you talk to large private network
      deployments of AFS they don't care about encryption.  If you look
      at the deployments at government installations they for the most
      part do not care either.  For the most part having security is a
      check list item but when the software is deployed they disable it
      because they care more about the raw speed.

Modernization does not have to require breaking backward compatibility. 
What it does require is that as any new functionality is added to the
protocol that the designers consider how the new data forms will be
represented using the older RPC variants and where they cannot be, how
the transition will take place and how those that deploy the new
functionality will be able to manage the fact that some data may only be
visible to a subset of the deployed clients for some extended period of
time. 

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.  Given that some of the NASA deployments have hardware
deployed with frozen software that is active for more than 20 years on
some missions, we know that some portions of the community will require
that much time.  For OpenAFS, our commitment to backward compatibility
may result in restricting volumeIds to 32-bits for a decade or more. 
There are implementation specific changes that can more efficiently use
the existing volumeId space in the meantime.  That should not stop some
other implementation of the protocol suite from starting from scratch
with the new protocols and ignoring the installed base.

Jeffrey Altman