Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Just earlier, I noticed that the secondary DRBD host ended up being "standalone", after syncing, and found this message in the syslog: block drbd1: Began resync as SyncTarget (will sync 45716 KB [11429 bits set]). block drbd1: BAD! sector=62193408s enr=1897 rs_left=-4 rs_failed=0 count=32 Pid: 9908, comm: drbd1_asender Not tainted 3.2.0-76-generic #111-Ubuntu Call Trace: [<ffffffffa013eb23>] drbd_try_clear_on_disk_bm+0x133/0x310 [drbd] [<ffffffffa01408af>] __drbd_set_in_sync+0x18f/0x340 [drbd] [<ffffffffa012fe28>] e_end_resync_block+0x78/0x100 [drbd] [<ffffffffa0136495>] drbd_process_done_ee+0x105/0x150 [drbd] [<ffffffffa013a514>] drbd_asender+0xf4/0x600 [drbd] [<ffffffffa0142180>] ? drbd_open+0xb0/0xb0 [drbd] [<ffffffffa01421e4>] drbd_thread_setup+0x64/0xf0 [drbd] [<ffffffffa0142180>] ? drbd_open+0xb0/0xb0 [drbd] [<ffffffff8108b96c>] kthread+0x8c/0xa0 [<ffffffff8166ef74>] kernel_thread_helper+0x4/0x10 [<ffffffff8108b8e0>] ? flush_kthread_worker+0xa0/0xa0 [<ffffffff8166ef70>] ? gs_change+0x13/0x13 block drbd1: peer( Primary -> Unknown ) conn( SyncTarget -> Disconnecting ) pdsk( UpToDate -> DUnknown ) block drbd1: asender terminated block drbd1: Terminating drbd1_asender block drbd1: bitmap WRITE of 1 pages took 0 jiffies block drbd1: 35 MB (8941 bits) marked out-of-sync by on disk bit-map. block drbd1: Connection closed block drbd1: conn( Disconnecting -> StandAlone ) block drbd1: receiver terminated block drbd1: Terminating drbd1_receiver Restarting the synchronisation with "drbdadm connect" seemed to work, at least it ran to 100% and said "up to date" again. Any idea what's happening here? Do I have to worry about data consistency?