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

[Felix Frank]

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