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 |