[DRBD-user] secondary sync behaviour after drbd stop and start

Gianluca Cecchi gianluca.cecchi at gmail.com
Wed Jun 22 08:29:06 CEST 2011

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

On Tue, Jun 21, 2011 at 11:51 PM, Lars Ellenberg  wrote:
> On Tue, Jun 21, 2011 at 05:55:24PM +0200, Gianluca Cecchi wrote:
>> hello,
>> using drbd 8.3.8 in CentOS 5.6 as provided by extra repo.
>> testing/simulating condition when secondary is taken down and some of
>> its data are modified before restart it...
>> (or you want to verify that if any problem/bug have modified them, you
>> come back to safety when you restart the secondary)

>> 3) mount backing device on secondary
> Do not bypass DRBD.
> Well, of course you can.
> But if you do, don't blame DRBD for not keeping track of your doings.

Thanks for your time.
Certainly it is not my intention to bypass DRBD. In fact in my e-mail
I tried to clarify that it was a simulation of changed data before
resync. My example was the deletion of a file, but in general it could
be something else, eventually not human driven... but caused by a
fault condition or something else...
My intent was to understand the correct approach in case of doubt
about secondary backing device access in the mean time when
disconnected (for example if you have not complete control of the
other side of the DRBD link, from an IT organization point of view...)

Are both the below steps equivalent from a result effect point of
view? What would you suggest/advice in such case?
drbdadm verify r0
drbdadm disconnect
drbdadm connect

As the verify action immediately comes back to prompt, is there a way
to automate the three steps in one atomic operation other than monitor
/var/log/messages or output of "cat /proc/drbd"?

drbdadm invalidate-remote r0

More information about the drbd-user mailing list