From: Lars Ellenberg <[email protected]> > 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 _______________________________________________ drbd-user mailing list [email protected] http://lists.linbit.com/mailman/listinfo/drbd-user
