[sheepdog] Is it necessary for outstanding io block leave/join event?

[Liu Yuan]

On 05/17/2012 04:01 PM, Liu Yuan wrote:

> On 05/17/2012 03:29 PM, MORITA Kazutaka wrote:
> 
>>>>
>>>> This assumption seems not necessary, at least to Farm, where I/O will
>>>> always be routed into objects in the working directory.
>> Really?  I thought that this problem does not depend on the underlying
>> storage driver.
>>
>> If there are 1 node, A, and the number of copies is 1, how does
>> Farm handle the following case?
>>
>>  - the user add the second node B, and there is in-flight I/Os on
>>    node A
>>  - the node A increments the epoch from 1 to 2, and the node B recovers
>>    objects from epoch 1 on node A
>>  - after node B receives objects to epoch 2, the in-flight I/Os on
>>    node A updates objects in epoch 1 on node A.
> 


With the second thought, seems that this case doesn't exist at all. When
Node B tries to recover the object from A, it will find the targeted
object is busy, and the recovery request will be placed on
sys->req_wait_for_obj_list.

Thanks,
Yuan

> 
> This is really a race problem for Farm for now. But I think we can
> exclude it by:
> 
> 1) ask recovery request in A to check if the requested oid is on the
> outstanding list.
> 2) if yes, A put it on a waiting list, if no, service the requests
> 3) the in-fly IO finished on A, check if there is any request on waiting
> list, if yes, resume it.
> 
> I think this algorithm will allow us a finer blocking for the request
> who really need blocking. Our current algo will block all the requests,
> most of them will be poor victim.
> 
> Thanks,
> Yuan