On Mon, Jun 15, 2009 at 11:18 AM, Hartmut Reuter<[email protected]> wrote: > > 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.
It may likewise be possible to avoid using Synccounter for the other proposed use; None of that should stop this proposal from advancing as it may give us leeway later when we need it. > 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. I don't see either being particularly logically cleaner. Derrick _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
