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 [email protected]. (and if you don't get a timely response, we know where they live.) Jeffrey Altman _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
