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

Federico Simoncelli federico.simoncelli at gmail.com
Thu Nov 27 18:03:56 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.

On Thu, Nov 27, 2008 at 5:38 PM, Lars Ellenberg
<lars.ellenberg at linbit.com> wrote:
>> 1) both servers: cs:Connected st:Primary/Primary ds:UpToDate/UpToDate
>> 2) server 2 is correctly shut down
>> 3) server 1: cs:WFConnection st:Primary/Unknown ds:UpToDate/Outdated
>> 4) booting server 2 in StandAlone mode is impossible since it has Outdated data
> careful. you use your own outdate-peer handler.
> so, server-1 "knows".
> but does server-2 know that it is outdated?
> who outdated it?
> when?

When you correctly shut down the server 2 the drbd service is cleanly
stopped. Running "drbdadm show-gi" shows that "Data was/is currently
up-to-date" is set to 0. This means that the resource is automatically
If then I shut down also the server 1 the drbd service is cleanly
stopped and running "drbdadm show-gi" shows that "Data was/is
currently up-to-date" is set to 1. So the server 1 is left to
This should also answer your following question:

>> Basically the Consistent status will always be turned into Outdated
>> because I have no way to check if the remote peer is primary. I assume
>> that a peer with "Consistent" status was incorrectly shut down and
>> can't become primary without manual intervention.
> you can now no longer reboot a single primary,
> whether cleanly or by power reset.

Yes, I can. The first node that is cleanly shut down is Outdated, the
last one is UpToDate (since it holds the last updated data).
I can boot as StandAlone the one with the UpToDate resource.

I just can't boot a single primary if both nodes were incorrectly shut
down. Manual intervention is needed to decide which one is the most
This is pretty reasonable.

>> I don't like the idea of a server waiting for a couple of days in the
>> boot sequence as a general rule and in this particular situation even
>> more since I moved the drbd script early at the beginning  before
>> clvmd.
> of course network and sshd have to be up first.

Network is obviously up. I don't need ssh to be up since my
outdate-peer handler doesn't need it. It just need cman in case it
needs to fence the remote peer. I need clvmd to start after drbd to
detect LVM.
Basically I'm trying to boot drbd as soon as an iscsi/aoe device would do.

Comments are welcome.


More information about the drbd-user mailing list