Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi Andreas, > From: Lars Ellenberg <lars.ellenberg [at] linbit> > > > 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? did you get any further on this original problem as we are battling the same problems for some time now, but with a slightly different configuration: XEN (4.0.1) Virtual machines, on top of DRBD (8.3.7)on top of LVM2 on top of RAID1 (pv=/dev/md3), on top of sda4, sdb4 regards, Micha Kersloot Altijd en overal bij je belangrijkste gegevens? http://www.exchange-alternatief.com/ KovoKs B.V. is ingeschreven onder KvK nummer: 11033334