[DRBD-user] Tracking down sources of corruption examined by drbdadm verify

Philipp Reisner philipp.reisner at linbit.com
Wed May 7 17:02:01 CEST 2008

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

Am Mittwoch, 7. Mai 2008 16:08:45 schrieb Tomasz Chmielewski:
> Philipp Reisner schrieb:
> (...)
> > The consequences are:
> >
> >   * You can not use online-verify with ReiserFS or swap-space.
> >     If you do so anyways you will get false positives.
> >
> >   * You can not use the data-integrity-alg feature with ReiserFS or
> >     swap-space.
> >     If you do so anyways you will get false positives.
> Logically, the above cases (reiser and swap verification errors) will only
> happen if DRBD and swap/reiser are being managed by the same kernel?
> In other words, mismatches shouldn't happen if:
> 1) we run DRBD on one machine
> 2a) other machines access DRBD via iSCSI or other means, and write
> swap/reiserfs on it.

In that case you will not the the false positives. The race between
the actual data transmission and the data modification of page under
IO happens on the iSCSI client machine (the initiator in iSCSI speak).

> 2b) other machines are being virtualized (Xen, VMware, KVM, etc.) on the
> machine running DRBD, and these virtual machines access DRBD

For fully virtualized solutions you are probably right. No false positives.

I do not know about (optimized) paravirtualized solutions. In case the
simply share the page from the guest block driver and the host block driver
backend, that will be affected as well. But I do not know how the Xen people
(or others) are doing that.

: Dipl-Ing Philipp Reisner                      Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Vivenotgasse 48, 1120 Vienna, Austria        http://www.linbit.com :

More information about the drbd-user mailing list