On 05/17/2012 07:41 PM, Liu Yuan wrote: > 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. >> Is there any agreement to remove simple store? If yes, I am going to rework abstracted store layer and Farm to get concurrent access of object. Thanks, Yuan |