AW: [DRBD-user] Some weird behaviour

Nuno Tavares nunotavares at
Thu May 13 21:51:52 CEST 2004

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

Em Thu, 13 May 2004 08:17:25 +0200, Martin Bene escreveu:

> Hi,
>> resource drbd0 {
>>   protocol = C
>>   fsckcmd  = /bin/true
>>   inittimeout=-10
> Eep, what are you doing here? With this inittimeout you don't give drbd
> sufficient time to connect with the 2nd node before trying to continue
> startup on ist own.
> If you use inittimeout, it should be as a last resort kind of thing with
> a timeout of -600 or something similar - this will still allow your
> system to start if just one system comes up after a power fail.

For testing purposes, -600 seems a lot to me!
Anyway, what are the alternatives? "load-only"? 
As a matter of fact, I've considered and commented out inittimeout, and
uncommented load-only, since my DRBD is heartbeat-managed.
Is this the right way to do it?

> However, if at all possible you should give drbd the chance to connect
> to the other box on startup so it can make the correct decision on where
> the newest data is located and in which direction to sync.

In the beginning of my tests it connected, but now it does not connect.
Perhaps it's that inittimeout issue.

>> If so, does it make any sense to set a (heartbeat) script to write a
> byte
>> to the DRBD, each time it switches to Primary?
> NO. Drbd already has the information needed to decide which node has the
> best data - you're just not giving it the time to actually connect and
> make that decision.

I'm just affraid that DRBD's algorithm contradicts what heartbeat thinks,
so I didn't really care about DRBD choosing WHO should be Primary.
Heartbeat will decide.

> At a guess this short inittimeout is also the caus for the
> "predetermined states are in contradiction to GC's" Messages: The box
> that used to be secondary decided to start on ist own because of
> inittimeout and subsequently was made primary be heartbeat, thus causing
> the message when the former primary connected.

Ok, it's just a warning then. The old data is still consistent,

Nuno Tavares

More information about the drbd-user mailing list