Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Mon, Dec 15, 2008 at 02:08:27PM -0800, Nolan wrote: > On Fri, 2008-12-15 at 11:48 +0100, Lars Ellenberg wrote: > > either "coincidence", or because of the added IO load (read the whole > > disk and checksum it) changes the timing. this has nothing to do with > > the "hanging" drbd resource, though. > > Interesting. > > But see below for more on the "hanging" drbd. > > >> 5261 S drbd_wait_peer_seq [drbd24_receiver] > > ^^^^^^^^^^^^^^^^^^ > > there. > > that is an interessting hint. > > > > this has been fixed in 8.2.7. > > Cool, I'll upgrade. Thanks for debugging this! > > To make sure I understand, upgrading is expected to fix verify hanging, > but not (or not necessarily) the DRBD device hanging? the "DRBD device hanging" was a by-product, and is expected to be fixed by that as well. > Because I had two more hanging VMs on Saturday evening. They DRBDs in > question seem to be stuck in WFBitMapT/WFBitMapS. this has a different cause, but is expected to be fixed in 8.2.7 as well. > Unfortunately I had to reboot both hosts to get things up and going > again, so this is all the info I have available. The kernel logs are > attached, the contents of the /proc/drbds are inlined: not useful, and too large for the list -> discarded. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed