[DRBD-user] Clarification on How-To

Nuno Tavares nunotavares at hotmail.com
Fri Sep 17 19:10:21 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.


On Thu, 16 Sep 2004 20:30:45 -0600, Alan Robertson >Nuno Tavares
>>This is *NOT* true, at least for 0.6.x, I still hadn't the time to 
>>switch to 0.7.x though.
>Exactly *what* is not true?  

"DRBD will never knowingly use out of date, and heartbeat will not

I assume here that "out of date" is a comparative result between both
DRBD. In that case, both nodes will keep to-be-mirror/secondary (not
to-be-mirrored) even if it's the most up-to-date, if you set DRBD in
passive mode (negative value in inittimeout).

>DRBD will never use out-of-date data 
>unless a
>human tells them otherwise?  If it does, then that's a major bug, 
>would require immediate attention.  That's pretty much all I said.

I think you're missing my point here. DRBD *should* allow to be
controlled externally (in terms of who's to-be-mirror[ed]). There are
times that device writable control is preferred over to
data-availability (my case). 

As I said, this might be different in 0.7.x, if DRBD is allowed to
sync in both directions, still keeping a PRIMARY and (1-*)
SECONDARY(IES). This should not be difficult, except for the fact when
concurrent changes have to be dealed with. At this time, I think the
PRIMARY should prevail... but this is subject to another thread, which
I'm not able to start, without looking at the code (with time).

>It doesn't matter which side is brought up as writable, and which as
>non-writable. That's not terribly important, since it's easily 
>What's really important is which copy of the data is treated as 
>good.  In
>the older versions, this was tied tightly to which side was 
>"master".  In
>recent versions, that's not true any more.

So we have some kind of full-duplex going on here? :)

>Perhaps you missed that the discussion was about getting started the 
>time.  This is a bit of a special case, since neither side has known 
>data yet.

I was not answering John, but rather correcting a potencial misleading
information. I just wanted to state that DRBD internal detection of
"who should be primary/writable" can be overridden.


These were some (very interesting) documents/sites I refered to while
writing the HOWTO, so this is not new to me, except for the fact that
I usually don't remember author's names, which explains my reference
to to it :)

The point here was explaining what I was talking about, in a practical

Thanks for adding the link to Linux-HA. BTW, there was a typo in [5].
It's linuxha.trick.ca, not linux-ha.trick.ca :)

Best regards,
Nuno Tavares

More information about the drbd-user mailing list