Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
I just tried to test the verify-alg by adding it to one of my resources,
and adjusting both ends, then ran the drbdadm verify command.
It clearly SEEMED to work. Lots of packets were flying back and forth, but
not much data, and the disks on both ends were reading at the sync rate...
BUT, when I purposely stomped directly on the backing store (overwrote 40
meg with zeros) for the secondary, nothing showed up in the verification.
Confused, I sync'd the primary, snapshotted the secondary and ran a
filesystem check... it failed quite badly... so my stomping appeared to
have been valid.
I then got a bit confused by the
Apr 8 14:23:02 gt6 kernel: drbd4: data-integrity-alg: <not-used>
log messages I was seeing on connection of the primary and secondary (I
broke the connection on purpose).
Then I realized that data-integrity-alg and verify-alg are two separate
things, but it got me thinking. So I went and set the data-integrity-alg
setting, adjusted, reconnected, and reran the verify command. Voila,
suddenly the system knew there were some out of sync blocks.
So, my post is basically: "Is there supposed to be a link between
data-integrity-alg and verify-alg? And if so, shouldn't it be documented
in the user's guide?"
(more info...)
admittedly, I've got 8.2.6rc2 on one end and 8.3.1 on the other... which
may explain this funny looking message that showed up on both ends:
Apr 8 14:47:43 gt3 kernel: drbd4: Writing the whole bitmap, due to failed
kmalloc
in context that is:
14:47:43 gt3 kernel: drbd4: Online verify found 45 4k block out of sync!
14:47:43 gt3 kernel: drbd4: conn( VerifyT -> Connected )
14:47:43 gt3 kernel: drbd4: Writing the whole bitmap, due to failed kmalloc
after a disconnect and reconnect (to get the out-of-sync blocks
sync'd), the fsck looks a lot better.
-Tom