[AFS3-std] RxOSD claim on 2 structure members
Matt W. Benjamin
matt@linuxbox.com
Sun, 7 Jun 2009 13:51:01 -0400 (EDT)
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