[DRBD-user] Some queries

Vic Berdin vic at digi.com.ph
Thu Dec 2 11:40:18 CET 2004

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

Hi Lars, everyone,

Thanks for your quick response. 

> -----Original Message-----
> From: Lars Marowsky-Bree [mailto:lmb at suse.de] 
> Sent: Thursday, December 02, 2004 5:35 PM
> To: Vic Berdin; 'Todd Denniston'
> Cc: drbd-user at linbit.com
> Subject: Re: [DRBD-user] Some queries

> The proper way to access a drbd device is to promote the node 
> you want to access it on to 'primary' status and then mount 
> the drbd device.
I see. Thanks for this very important reminder.

> > Now, upon turning back "on" the primary node, I notice that 
> /proc/drbd 
> > status on both nodes does not seem to detect the existence 
> of the another:

> Is your network configuration correct? And it could take a 
> couple of seconds for drbd to reconnect, so maybe you should 
> just wait a second.

I'm doing these tests on an LVS-DR setup. Is this OK with drbd? I mean the
VIP is "up" on both nodes (but only one can do arp)?

> Is drbd itself part of your boot sequence? And you shouldn't have
> configured 'load-only' or some such.

Yes it is. I'm doing a `drbd start` during start-up, and definitely did not
configure a "load-only" setup.

>> Connection/mirroring will only resume if I manually do a `drbd 
>> reconnect` on the newly restarted (secondary) node. And this action 
>> seem to perform a complete replication of the primary:

> This is correct behaviour of drbd in case the primary failed; you should
> use 0.7.x if you want to get smarter resyncs all the time.
> 0.6.x can only 'smartly' resync if the secondary fails and the primary
> stays up.

I see. Now this brings me back to my post yesterday about the gcc-2.95.x
problem with -Wpadded. The current 0.7.6 release is using this compile
option that's not supported by gcc-2.95.x. Is there a workaround to this
other than upgrading to a gcc-3.3.x?

[messages snipped]
> Yes, the side effect is that you are killing the generation 
> counters and that may cause various bugs and data corruption. 
> /var/lib/drbd may not be volatile; that's a severe setup bug.
I understand completely.

Once more, thanks very much!

BR - Vic

More information about the drbd-user mailing list