Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi all. I noticed that promoting to primary a "ds:Consistent/DUnknown" device automatically triggers a "/sbin/drbdadm outdate-peer". 1) During normal operation the status is: 0: cs:Connected st:Primary/Primary ds:UpToDate/UpToDate C r--- 2) Unplugging the cable the node 1 fences the node 2 and its status becomes: 0: cs:WFConnection st:Primary/Unknown ds:UpToDate/Outdated C r--- 3) Booting the node 2 (keeping the cable disconnected) and running "drbdadm adjust all" (for debug purpose) I can see that on this side the status is: 0: cs:WFConnection st:Secondary/Unknown ds:Consistent/DUnknown C r--- 4) Running the command "drbdadm sh-b-pri all" on node 2 (as the drbd init script would do after adjust and wait-connect) the "/sbin/drbdadm outdate-peer" is triggered. The problem here is that the node 1 (the one holding the updated data) get fenced without reason and it also risks to become later a SyncTarget losing the updated data. I suppose that the problem is my outdate-peer which just fences the node without actually outdate it. Even if this is the reason I think that a "Consistent" device should not be allowed to become primary (fencing the remote node) without any confirmation. What do you think about this? Am I missing something? My current configuration: become-primary-on both; allow-two-primaries; after-sb-0pri discard-zero-changes; after-sb-1pri discard-secondary; after-sb-2pri disconnect; fencing resource-and-stonith; outdate-peer "/usr/lib/drbd/obliterate-peer.sh"; The "/usr/lib/drbd/obliterate-peer.sh" script is available at: http://people.redhat.com/lhh/obliterate (It basically fences the other node using "fence_node" and it returns the exit code 7 on success) -- Federico.