Re: crc error when decode_message?

[Ning Yao <zay11022@gmail.com>]

2015-03-16 22:06 GMT+08:00 Haomai Wang <haomaiwang@gmail.com>:
> On Mon, Mar 16, 2015 at 10:04 PM, Xinze Chi <xmdxcxz@gmail.com> wrote:
>> How to process the write request in primary?
>>
>> Thanks.
>>
>> 2015-03-16 22:01 GMT+08:00 Haomai Wang <haomaiwang@gmail.com>:
>>> AFAR Pipe and AsyncConnection both will mark self fault and shutdown
>>> socket and peer will detect this reset. So each side has chance to
>>> rebuild the session.
>>>
>>> On Mon, Mar 16, 2015 at 9:19 PM, Xinze Chi <xmdxcxz@gmail.com> wrote:
>>>> Such as, Client send write request to osd.0 (primary), osd.0 send
>>>> MOSDSubOp to osd.1 and osd.2
>>>>
>>>> osd.1 send reply to osd.0 (primary), but accident happened:
>>>>
>>>> 1. decode_message crc error when decode reply msg
>>>> or
>>>> 2. the reply msg is lost when send to osd.0, so osd.0 do not receive replay msg
>>>>
>>>> Could anyone tell me what is the behavior if osd.0 (primary)?
>>>>
>
> osd.0 and osd.1 both will try to reconnect peer side, and the lost
> message will be resend to osd.0 from osd.1
So I wonder if different routing path delays the arrival of one
message, then the in_seq would be setting ahead, then based on the
logic. Later, if the delaying message arrives, it will be dropping and
discard. Thus, if it is just a sub_op reply message as xinze
describes, how ceph works after that? It seems repop of the write Op
will be waiting infinite times until the osd restart?

>
>
> --
> Best Regards,
>
> Wheat
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html