[OpenAFS-devel] [grand.central.org #124130] Re-opening the discussion (fwd)

[Jeffrey Altman]

Hartmut Reuter wrote:
> The best thing would be to create a new struct AFSFetchStatus64 with an
> afs_uint64 field for the file size and some more fields (also spares)
> for the purpose we and obviously also other groups are abusing the
> SyncCounter.
> 
> Then, of course, some new RPCs are needed to replace in the long run the
> current RPCs which use AFSFetchStatus. This would also give us the
> opportunity to get rid of some old stuff e.g. AFSVolSync which is
> provided by the cache manager for a number of RPCs, but nowhere examined
> at all.

We need a new AFSFetchStatus64 (and everything else that has a time) so
that we can support 64-bit time values.  The question is what else do we
need to add?  We can always add new RPC values when we add new
functionality.  Doing so provides a built in negotiation mechanism:

 * clients only ask for what they support
 * servers only send what they support

The question is simply what are all of the things we know today that
need to go into the new RPCs and writing a proposal document to be
sent to afs3-stds so that the protocol discussion can take place.
The protocol is not limited to OpenAFS.

> Doing this, however, we must make sure not to get an overlap in the RPC
> numbers! When I modified the code for MR-AFS and later for OpenAFS+OSD I
> let a gap between the last RPC-number used by OpenAFS and the first one
> I used.  This gap has shrunk to to eight (65543-65550) in the meantime.

This is why we have a registration system.  Developers must not select
their own RPC values.  The values must be issued by the registrars.
OpenAFS gatekeepers cannot issue RPC assignments.  Send requests for
RPCs to registrar@grand.central.org.  (and if you don't get a timely
response, we know where they live.)

Jeffrey Altman