You are right, Sage I have lost sight of that the uncommited_pn would be replaced by the new accept_pn when uncommitted_value being re-proposed. Thanks again and I rewrote the scenario for anyone who may have a same question below. For simplicity, I used a increasing integer indicated pn, branket for commited value and parens for uncommited. 1, m1 as the leader, and all node have the same last_commited at begin, then m1 propose a new value ‘2', which then be accept by m1 and m3: m1: [1, pn=123] (2, pn=123) m2: [1, pn=123] m3: [1, pn=123] (2, pn=123) m4: [1, pn=123] m5: [1, pn=123] 2, Unfortunatly, both m1 and m3 go down, and m2 become leader without knowledge about the propse, and it propose a new value ‘3' m1: [1, pn=123] (2, pn=123) down m2: [1, pn=123] (3, pn=124) m3: [1, pn=123] (2, pn=123) down m4: [1, pn=123] m5: [1, pn=123] 3, Then m2 goes down before send anything to others, then m1, m3 recovered and commit value ‘2’ with the quorum m1, m3, m4 m1: [1, pn=123] [2, pn=125] m2: [1, pn=123] (3, pn=124) down m3: [1, pn=123] (2, pn=125) m4: [1, pn=123] (2, pn=125) m5: [1, pn=123] 4, Before the commit message sent to others, m1 and m3 go down again. So value ‘3’ only commit on m1. Then m2 become leader once more. m1: [1, pn=123] [2, pn=125] down m2: [1, pn=123] (3, pn=124) m3: [1, pn=123] (2, pn=125) down m4: [1, pn=123] (2, pn=125) m5: [1, pn=123] 5, Leader m2 see the uncommited value ‘2’, with larger pn than ‘3', so it re-propse value ‘2’ with a newer pn m1: [1, pn=123] [2, pn=125] down m2: [1, pn=123] [2, pn=126] m3: [1, pn=123] (2, pn=125) down m4: [1, pn=123] [2, pn=126] m5: [1, pn=123] [2, pn=126] > On 28 Nov 2017, at 9:06 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > > -- 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
