[OpenAFS-devel] Re: RxOSD claim on 2 structure members

[Hartmut Reuter]

Hi,

After all the problems with claiming the SyncCounter field for RxOSD I
would like to make a revised proposal for how AFS+RxOSD could use a
field in struct FetchStatus. Instead of "SyncCounter" we could use
"ResidencyMask" which has become obsolete since MR-AFS isn't used
anymore at any site. When I decided to use the "SyncCounter" field as
"Protocol" MR-AFS was still alive at our site so it would have been
filled differently by the MR-AFS fileservers and could not be used for
the new RxOSD code.

The field ResidencyMask was introduced by my patch
client-64bit-file-size-support-20011031 by renaming the former field
"SegSize". Since that time the OpenAFS fileserver fills this field with
'1' which corresponds to the local_disk residency in MR-AFS. Presently
this field isn't interpreted any more by the client.

The AFS+RxOSD client presently copies the contents of "Protocol" (alias
SyncCounter) into the new field "Protocol" of struct vcache. If we would
copy instead the contents of "ResidencyMask" into avc->Protocol we would
get a conflict with the present bit meaning of "1" which is VICEP_ACCESS
and not the default rx-fileserver protocol (which is 0 as the default
contents of SyncCounter used to be). This conflict could be solved
either by using another bit for VICEO_ACCESS or by not having a
one-to-one correspondence between ResidencyMask and avc->Protocol. The
latter one is the smaller modification, but the first one may appear as
 logically cleaner.

Any comments?

Thanks,
Hartmut

Matt W. Benjamin wrote:
> Hi,
> 
> A priority for openafs is to merge the rxosd changeset.  One obstacle
> to merging is the use of two 'unused' members in existing structures
> without prior coordination.  We've been asked to move discussion of
> the topic into this forum, which we hereby do.
> 
> The following diffs summarize the changes:
> 
> afsint.xg
> 
> 1. SyncCounter field in AFSFetchStatus (no longer used in openafs) is
> renamed Protocol, claiming it.
> 
> @@ -99,7 +99,7 @@ 
>   afs_uint32 ClientModTime;
>   afs_uint32 ServerModTime;
>   afs_uint32 Group; 
> - -  afs_uint32 SyncCounter;
> +    afs_uint32 Protocol;
>   afs_uint32 dataVersionHigh; /* For AFS/DFS translator, hi
> bits of dvn */ 
>   afs_uint32 lockCount; afs_uint32 Length_hi;

@@ -115,6
> +115,10 @@ afs_uint32 SegSize; };
> 
> volint.xg
> 
> 1. struct volintInfo is altered, spare0 and spare3 spare fields are 
> renamed (claimed) as osdFlag and filequota, respsectively
> 
> struct volintInfo { 
> @@ -111,10 +130,10 @@ int maxquota; int size;
> afs_int32 flags;            /* used by the backup system */ 
> -- afs_int32 spare0;           /* Used to hold the minquota value */ 
> + afs_int32 osdPolicy;          /* whether and how to use object
> storage */ afs_int32 spare1;           /* Used to hold the weekuse
> value */ - -    afs_int32 spare2; - -    afs_int32 spare3; +
> afs_int32 spare2;           /* Used to hold the updateCount  */ +
> afs_int32 filequota; /* max. number of files MR-AFS / AFS+OSD */
> 
> As a starting point for discussion, I wish to make the following
> proposal:
> 
> 1. as apparent patch maintainer for fetchvstatus, the only change I
> am aware of (so far) which conflicts with the rxosd change, in
> claiming the AFSFetchStatus SyncCounter, I propose that SyncCounter
> be allocated to rxosd, renaming to Protocol
> 
> 2. I propose that fetchvstatus be added to the list of features to be
> accommodated in the upcoming round of extended AFSFetchStatus
> discussions
> 
> 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,
> 
> Matt
> 


-- 
-----------------------------------------------------------------
Hartmut Reuter                  e-mail 		reuter@rzg.mpg.de
			   	phone 		 +49-89-3299-1328
			   	fax   		 +49-89-3299-1301
RZG (Rechenzentrum Garching)   	web    http://www.rzg.mpg.de/~hwr
Computing Center of the Max-Planck-Gesellschaft (MPG) and the
Institut fuer Plasmaphysik (IPP)
-----------------------------------------------------------------