[AFS3-std] Re: [OpenAFS-devel] convergence of RxOSD, Extended Call Backs, Byte Range Locking, etc.

[Jeffrey Altman]

Felix Frank wrote:
> Jeffrey Altman wrote (Fri Jul 24 2009 17:39:44 GMT+0200 (CEST) )
>> Hartmut Reuter wrote:
>>
>>> I can't use the vnode->lock for this kind of locking, anyway, because
>>> the End-of-I/O-rpc wouldn't run in the same thread. So I have planned a
>>> counter for ongoing reads (write can only start if that came down to 0)
>>> a counter for waiters (to know whether End-of-I/O-rpc has to wake
>>> someone or just can free the struct) and, of course a writer field which
>>> contains the ip-address of the writing client or 0 if there is no write
>>> in progress.
>>>
>>> But all these are implementation details which have nothing to do with
>>> the AFS3 protocol and can be changed later if it seems appropriate.
>
> <snip>
>
>> The
>> RXAFS_OSD_StartFetchData/RXAFS_OSD_ExtendFetchData/RXAFS_OSD_EndFetchData
>> and
>> RXAFS_OSD_StartStoreData/RXAFS_OSD_ExtendStoreData/RXAFS_OSD_EndStoreData
>> rpcs are going to have exactly the same issue as
>> SetLock/ExtendLock/ReleaseLock rpcs.   Jeff's point is that we must not
>> repeat the same mistakes from our past.
>
> Adding such additional RPCs is fine, and OSD-aware clients will be
> capable of using them. I believe that what Hartmut proposed is a means
> to also keep legacy clients from messing up data and dataversions. The
> fileserver's ability to do so is limited, and for that particular
> usecase, no additional tokens of identity can be introduced, anyway.
>
> Of course, given that the fileserver is responsible for data transfers
> to and from the OSDs in this case, it could just obtain an appropriate
> lock on the client's behalf. I'm not entirely sure about the semantic
> implications of such a scheme though. Maybe I'm also over-thinking this
> quite a bit...
>
> Regards
>  - Felix
The RPCS
  RXAFS_OSD_StartFetchData (FID, offset, length)
  RXAFS_OSD_ExtendFetchData
  RXAFS_OSD_EndFetchData -> (AFSFetchStatus)
  RXAFS_OSD_StartStoreData (FID, offset, length)
  RXAFS_OSD_ExtendStoreData
  RXAFS_OSD_EndStoreData -> (AFSFetchStatus)
have to be between the OSD aware client and the file server.   Otherwise
the file server cannot use the Start messages to break the callbacks
necessary to maintain AFS semantics, enforce serialization between store
and fetch operations, and enforce mandatory callbacks when implemented. 
Since the file server is the coordinator, not the OSD, supporting
non-OSD clients is not an issue.  The file server has all of the
knowledge it requires to do so.

Jeffrey Altman