On Mon, 27 Nov 2017, Kang Wang wrote: > hi > > I read the code of ceph paxos recently, and have a question about it, which, in my opinion, may violate the consistency. > > Assume we have five monitor node m1, m2, m3, m4, m5, the prior one has larger rank than the back one. > > Consider the situation as below: > > 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 2 > m2: 1 > m3: 1 2 > m4: 1 > m5: 1 > > 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 2 down > m2: 1 3 > m3: 1 2 down > m4: 1 > m5: 1 > > 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 2 > m2: 1 3 down > m3: 1 2 > m4: 1 2 > m5: 1 > > 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 2 down > m2: 1 3 > m3: 1 2 down > m4: 1 2 > m5: 1 > > 5, Leader m2 see the uncommited value ‘2’, but discard it by compare uncommitted_pn in function handle_last, so it commit value ‘3’ with the quorum m2, m4, m5 > m1: 1 2 down > m2: 1 3 > m3: 1 2 down > m4: 1 3 > m5: 1 3 This is what the last->uncommitted_pn value is for. I believe this prevents us from using 2's pn (and uncommitted value) because 3's pn is larger. Can you verify? Thanks! sage > > Now we see the value ‘2’ has been commited, but lost soon. Am I right on it? > > > Thanks > WANG KANG > > -- > 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 > >
