On 05/19/2016 08:58 AM, d tbsky wrote:
2016-05-19 23:35 GMT+08:00 Lars Ellenberg <[email protected]>:
Even though the subject does not mention drbd online verify,
you still want to read this:
"Re: Explained: Digest integrity check FAILED"
http://lists.linbit.com/pipermail/drbd-user/2011-March/015751.html
http://www.gossamer-threads.com/lists/drbd/users/21091?do=post_view_threaded#21091
or gmane or any other ML archive.
you could run with data-integrity enabled for a while, and check for
"Digest mismatch, buffer modified by upper layers during write"
messages in kernel logs.
hi:
I already try to enable data-integrity check after the
verify/resync failed, but it didn't help. the verify/resync was not
correct and there are no "Digest mismatch" messages in kernel logs.
I now will write a script to verfiy/resync the resource volumes
one by one, to see if all the resources volumes can be verify/synced
correctly.
or if you have other ideas need to try at the cluster please tell
me. the cluster is running many testing vms, so the corruption is
affordable for these vms.
It could very well be a sort of race condition like you mentioned
earlier. If the block is written on the Primary, but the verify is
checksumming the backing disks before the write makes it down to disk on
the Secondary (block is on the wire, in a buffer, etc), the verify could
be coming up with false positives.
This is described in one of LINBIT's blog posts found here:
https://blogs.linbit.com/p/138/trust-but-verify/
thanks a lot for your help!!
Regards,
tbskyd
_______________________________________________
drbd-user mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/drbd-user
--
: Matt Kereczman
: [email protected]
: +1 (503) 573-1262 x205
: LINBIT | Keeping the Digital World Running
: DRBD -- Heartbeat -- Corosync -- Pacemaker
_______________________________________________
drbd-user mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/drbd-user
