Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Wed, Apr 08, 2009 at 02:54:44PM -0700, Tom Brown wrote: > > 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? no. > 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 that is something completely different, and is actually harmless for the functionality. an optimization did not work because there was previously no memory available from an "atomic" context. > 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. I guess when you "stomped" over it, the verify process has already been past that area. you should have just restarted the verify process, and it should have picket up on that stomping. -- : Lars Ellenberg : LINBIT HA-Solutions GmbH : DRBD®/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed