On Thu, Jun 13, 2019 at 10:06 AM huang jun <hjwsm1989@xxxxxxxxx> wrote: > > Hi,all Jun, sorry for the latency. got stuck by something else. =( > I recently read the ceph-monstore-tool code, and have a question about > rebuild operations. > In update_paxos() we read osdmap, pgmap, auth and pgmap_pg records to > pending_proposal(a bufferlist) as the value of the key paxos_1, and > set paxos_pending_v=1, > and set the paxos_last_committed=0 and paxos_first_committed=0; > > My question is if we start the mon after rebuild, let's say there is > only one mon now, the mon will not commit the paxos_pending_v=1, and > if we change the osdmap by 'ceph osd set noout' the new pending_v=1 > will overwrite the former one in rebuild, so i think we don't need to agreed, unless the initial monmap requires more monitors. it will prevent the monitor from forming a quorum to write to the store. yeah, the paxos/1 will be overwritten by the first proposal at rebuilding the mondb. but i think we still need to store the "rebuild" transaction as a paxos proposal, as we need to apply the transaction on the sync client side, after the it syncs the chunks with the sync provider. probably we should just bump up the last_committed to a non-zero number, to preserve the rebuild transaction. actually, i was testing the fix of the issue you are talking about using the PR of https://github.com/ceph/ceph/pull/27465. but i didn't get a chance to look into the reason why it still failed.. > set paxos_1=pending_proposal, paxos_pending_v=1 in 'ceph-monstore-tool > rebuild'. > > Thanks! > _______________________________________________ > Dev mailing list -- dev@xxxxxxx > To unsubscribe send an email to dev-leave@xxxxxxx -- Regards Kefu Chai _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
