Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
2016-05-20 3:44 GMT+08:00 Matt Kereczman <matt at linbit.com>:
> 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/
Hi:
the drbd resource is idle when verify/resync. the vm running above
it is shutdown, so no one is using it. but it still can not get
verify/resync until no other resource/volume is doing verify.
so the race condition here is the verify process between different
resource/volume. is that possible in theory? I need to do more
testing. but one thing I can sure is:
if the resource/volume verify process report 0 oos, then it won't be
affected, it will always report 0 oos under next verify/resync.
Regards,
tbskyd