2015-03-16 22:06 GMT+08:00 Haomai Wang <haomaiwang@xxxxxxxxx>: > On Mon, Mar 16, 2015 at 10:04 PM, Xinze Chi <xmdxcxz@xxxxxxxxx> wrote: >> How to process the write request in primary? >> >> Thanks. >> >> 2015-03-16 22:01 GMT+08:00 Haomai Wang <haomaiwang@xxxxxxxxx>: >>> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
