[AFS3-std] RxOSD claim on 2 structure members

[Felix Frank]

Jeffrey Altman wrote (Mon Jun 08 2009 02:37:50 GMT+0200 (CEST))
> Matt W. Benjamin wrote:
>> 3. I would request that any other claimants of SyncCounter or of the spare0 and spare3 members in volintInfo (claimed as osdPolicy and filequota in rxosd) disclose their use here, or otherwise state here how they would be harmed by allocating these members to rxosd.

Thanks for bringing this up.

> This is an impossible request.  Not all parties that may have developed
> private uses for these fields participate on this list.  
> 
> The fact that at least two parties that are known have created private
> uses for field that are otherwise unused in the OpenAFS implementation
> simply demonstrates that reusing otherwise allocated protocol components
> is dangerous and should not be done. 

I agree that there are fundamental problems with this. I'd like to point 
out though, that those will not be introduced by this claim - they 
already exist. The fact that different parties have different uses for 
the same field implies that there are some servers and clients connected 
to AFS that *will* not interoperate. I suggest that an alternate view on 
this claim is that it will help putting an end to such liabilities.

> Given the known collision I will not support the reuse of the
> FetchStatus SyncCounter field for any use. 
 >
> We require new versions of many RPCs.  What we should start doing to
> move the process forward is to collect a list of known requirements for
> as many known sources as possible so that a single revision of each RPC
> can be issued that addresses the protocol needs of the various
> implementors for the next several years.   As an example of a requirement:
> 
>    1. Package RXAFS
>          1. 32-bit unsigned value for OSD Protocol Version. 
>                1. Affected RPCs: AFSFetchStatus
>          2. 64-bit unsigned value for Read-Only Volume Version
>                1. Affected RPCs: AFSFetchStatus
>    2. Package AFSVol
>          1. 32-bit signed value for OSD use of object storage
>                1. Affected RPCs: SetInfo, ListVolumes, ListOneVolume
>          1. 32-bit signed value for OSD updateCount value
>                1. Affected RPCs: SetInfo, ListVolumes, ListOneVolume
>          2. 32-bit signed value for OSD max number of files
>                1. Affected RPCs: SetInfo, ListVolumes, ListOneVolume
> 
> This list should be extended to include all of the changes necessary to
> support 64-bit time, long volume names, 64-bit volume IDs, volume UUIDs,
> cell UUIDs, etc.
> 
> Once such a list of requirements is compiled (and I suggest this be done
> on a wiki page to start which can eventually be published as an Internet
> Draft when it begins to stabilize) the afs3 standardization community
> can begin to layout new data structures and RPCs that can support all of
> the functionality we expect to need over the next several years.   It
> might prove in the end that we will miss something and require a
> subsequent RPC revision.  However, the end result will be a much more
> stable protocol and set of client/server implementations.

So you propose postponing rxosd integration until the protocol has 
undergone thorough restructuring?

If that ends up being a consensus, I urge you to put out the call for 
participation as soon as possible.

Regards
  - Felix