Thanks for the quick reply:-)
Is it possible that the client resubmit M after the new "Peering" process completes but before the processing of M is completed on OSD.X? I'm asking this because as far as I understand, if the "dup" req is not already completed, the OSD will put it in the "waitingg_for_ondisk" and "waiting_for_ack" queue which are only accessed when the previous repop completes "commit" and "apply" process and are not accessed in this scenario since there is no such "previous repop".
Thanks:-)
At 2016-12-16 08:35:15, "Gregory Farnum" <gfarnum@xxxxxxxxxx> wrote:
>On Thu, Dec 15, 2016 at 4:17 PM, xxhdx1985126 <xxhdx1985126@xxxxxxx> wrote:
>>
>> Hi, everyone.
>>
>>
>> What will the OSD do in the following scenario?
>>
>> Say, a MOSDRepop M that is initiated at client A is being processed on an OSD.X, during which the acting primary turn "down" due to some error and OSD.X is chosen to be the new acting primary. Since OSD.X is a replica OSD for MOSDRepOp M, how can client A be acked after OSD.X finished the processing of M? Or does A be acked at all in this kind of circumstances?
>
>The client is not acked by OSD.X, but when the client sees the OSDMap
>marking down the previous primary, it will resubmit MOSDOpM to OSD.X
>(and increment the retry counter). OSD.X will notice that MOSDOpM has
>already been completed and reply with the same answer it gave
>previously.[1]
>-Greg
>[1]: Barring protocol or implementation bugs. There have historically
>been some issues with things like (successful) deletes returning
>ENOENT instead of 0; I don't remember if all the known ones have been
>squashed or not.
?韬{.n?壏煯壄?%娝?檩?w?{.n?壏渮?u朕楕Ф洝塄}财爖?j:+v墾 畐娻2娹櫒璀??摺玜囤?z夸z罐楘+凒殠娸?w棹f
