Hi, Steven >From my reading of Y Amir's paper, the ring id needs to be stored in "stable storage" which I think he meant by persistent memory like disk which can survive a processor failure or reset/restart. I believe "token_ring_id_seq" variable in corosync is the ring id. I do see this id being recorded in /var/lib/corosync directory. For our system configuration, each processor operates on memory disk. In other words, the ring id is not really persisted through processor reset or failure. The file will be gone each time a processor resets. It looks to me that Corosync appears functioning as expected. I think the implication of non-persistent ring id means that the new node will not receive messages that have been circulated during its failure. Is this correct? If this is the only implication, then we are O.K. because our application layer is to make sure that useful events and states are to be synced with the newly recovered processor. Could you comment on this? Are there other problems or implications if the ring id is not persisted? Is there any other information that also has to be persisted for the algorithm to work? Thanks, Qiuping Li _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
