[DRBD-user] very large out-of-sync (oos) value yet drbd-overview claims UpToDate/UpToDate

[Lonni J Friedman]

Thanks, that answers my 2nd question, but not my 1st question.
Shouldn't drbd-overview be treating this as a not UpToDate scenario?

On Thu, Nov 1, 2012 at 6:08 AM, Dan Barker <dbarker at visioncomm.net> wrote:
> There is an on-error event handler. Mine sends me email if verify fails
> (runs weekly, one resource each of M, Tu, W, Th nights).
>
> Dan
>
> In my Global "handlers" section:
>
> out-of-sync      "/usr/lib/drbd/notify-out-of-sync.sh <myemail>";
>
>
>
> -----Original Message-----
> From: drbd-user-bounces at lists.linbit.com
> [mailto:drbd-user-bounces at lists.linbit.com] On Behalf Of Lonni J Friedman
> Sent: Wednesday, October 31, 2012 6:02 PM
> To: drbd-user at lists.linbit.com
> Subject: [DRBD-user] very large out-of-sync (oos) value yet drbd-overview
> claims UpToDate/UpToDate
>
> I've got a drbd setup with 8.3.11.  I ran a manual verify, and once it
> completed it reported:
>
> [23479.620066] block drbd0: Online verify  done (total 23136 sec;
> paused 0 sec; 73748 K/sec)
> [23479.702176] block drbd0: Online verify found 9651098 4k block out of
> sync!
> [23479.745988] block drbd0: conn( VerifyT -> Connected )
> [23479.788996] block drbd0: helper command: /sbin/drbdadm out-of-sync
> minor-0
> [23479.839348] block drbd0: helper command: /sbin/drbdadm out-of-sync
> minor-0 exit code 0 (0x0)
> [23479.961245] block drbd0: bitmap WRITE of 2763 pages took 34 jiffies
> [23480.006527] block drbd0: 37 GB (9651098 bits) marked out-of-sync by
> on disk bit-map.
>
> This isn't entirely surprising, as the secondary node was down for a
> long time due to hardware problems.  However, what is surprising is
> that drbd-overview still reports that everything is UpToDate:
> $ drbd-overview
>   0:sdb  Connected Secondary/Primary UpToDate/UpToDate C r-----
>
> Shouldn't this huge number of out of sync bits cause drbd-overview to
> report something other than UpToDate for the Secondary node?   If not,
> then how does one actually programattically detect that a verification
> has failed?  Parsing dmesg is going to be a huge kludge, and not
> likely to be reliable.
>
> thanks