[DRBD-user] Consistent device to primary fences remote node

Federico Simoncelli federico.simoncelli at gmail.com
Wed Nov 26 11:15:00 CET 2008

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

What do you think about this? Am I missing something?

My current configuration:

become-primary-on both;
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:


(It basically fences the other node using "fence_node" and it returns
the exit code 7 on success)


More information about the drbd-user mailing list