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 noticed the following after upgrading a simple cluster > > to drbd-8.3.10 in the kernel logs. > > Upgrading from what DRBD version? Upgrading from 8.3.9. However, I just checked the logs (yes, should have done this in the first place). The first occurrence was on Nov 26th, running 2.6.32.26 and obviously 8.3.9: drbd0: ASSERT( from_tnr - cnr + i - from == mx+1 ) in /kernel/drbd/drbd-8.3.9/drbd/drbd_actlog.c:478 drbd0: ASSERT FAILED: drbd_al_read_log: (rv == 0) in /kernel/drbd/drbd-8.3.9/drbd/drbd_actlog.c:504 > Any crash or reset in between? No crashes, the machine is stable, but reboots due to kernel updates. The asserts are usually logged once after reboot, i.e. first connect after module load. I was just able to reproduce them by reloading the kernel module on the secondary node: # drbdadm down all; rmmod drbd; modprobe drbd; drbdadm up all dmesg output: ... block drbd0: Terminating worker thread drbd: module cleanup done. drbd: initialized. Version: 8.3.10 (api:88/proto:86-96) drbd: GIT-hash: 5c0b0469666682443d4785d90a2c603378f9017b build by @build.k9, 2011-02-07 12:14:11 drbd: registered as block device major 147 drbd: minor_table @ 0xffff880204e5d000 block drbd0: Starting worker thread (from cqueue [5544]) block drbd0: disk( Diskless -> Attaching ) block drbd0: ASSERT( from_tnr - cnr + i - from == mx+1 ) in /kernel/drbd/drbd-8.3.10/drbd/drbd_actlog.c:514 block drbd0: ASSERT FAILED: drbd_al_read_log: (rv == 0) in /kernel/drbd/drbd-8.3.10/drbd/drbd_actlog.c:540 [38 times] block drbd0: Found 18 transactions (1031 active extents) in activity log. ... Also, please note that the asserts are logged on the secondary node only. > Volatile caches involved? Unlikely, at least none I'm aware of. > When did you last do "create-md"? Good question. Seems a litte while ago, I don't know. dump-md just says "v08", but no date. Any way to retrieve this? > > Still, something to worry about? > > If that's a one-time event, than I'd say strange, but so what. No, it seems to happen every time after loading the module > If it happens more often during attach, then that would be something > worth investigating further. I'd appreciate that! ;-) > I still suggest to run an online verify just in case, as these asserts > could under certain circumstances indicate that there may have been a > resync that could have been resyncing less than actually necessary. I run a verify weekly, there are usually a couple of blocks out of sync: Dec 5 17:00:33 drbd0: Online verify found 2 4k block out of sync! Dec 12 17:24:40 drbd0: Online verify found 3 4k block out of sync! Jan 9 08:50:54 drbd0: Online verify found 1 4k block out of sync! Jan 16 09:51:54 drbd0: Online verify found 1 4k block out of sync! Jan 23 10:07:32 drbd0: Online verify found 2 4k block out of sync! Jan 30 10:30:06 drbd0: Online verify found 2 4k block out of sync! Feb 6 09:44:18 drbd0: Online verify found 4 4k block out of sync! Something else to worry about? I've just activated the data-integrity-alg option. We'll see if that helps. > [that's intentionally vague ;-)] Your answer or my bug report? ;-) Walter -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl