Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
From: Lars Ellenberg <lars.ellenberg at linbit.com> > Ok, corrected to 8.3.11: > > > Kernel 3.1.0 / DRBD 8.3.11 > > Nothing directly DRBD related in the stack traces. Yes, makes sense for the md_resync, but what for the KVM process? It does access its device via DRBD, so is the stacktrace incomplete? (missing DRBD layer?). > But you have one kvm in: > kernel: [2009644.546925] [<ffffffffa00939d1>] ? wait_barrier+0x87/0xc0 [raid1] > and md1_resync in > kernel: [2009644.547433] [<ffffffffa0093917>] ? raise_barrier+0x11a/0x14d > [raid1] > > Looks like MD is stepping on it's own toes there. Stepping on one's own toes is something one isn't supposed to do, right? ;-) I might raise the issue with the MD developpers but at the moment I am still confused why DRBD did behave like it did. How would DRBD behave when the backing device blocks hard? regards, Andreas