Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Am 07.11.2014 09:46, schrieb Lars Ellenberg: > Right there. > DRBD config setting is ko-count. > Also, please use drbd 8.4 (where that would default to 7, iirc). Hello Lars, thanks for your answer. The ko-count seems promising but how to deal with such a problem on the primary? That would stilly need to detach to go on in diskless mode, am I right about this? I can seen that generally the behaviour of the raid card is wrong and should be investigated but I can imagine other situations where DRDB has to handle a problem like this e.g. a raid card getting totally unresponsive for some reason. I assume this has to be dealt with disk-timeout, right? And yes I know we should upgrade to 8.4. and we are in point of doing this but I still have to do some testing before touching this setup and it would be nice if I could get all those config right with the upgrade. > See above: ko-count. > also, you could have used --force disconnect (if no other drbdsetup is > blocking yet), or instead resetting the other box, simply cut the tcp > connection (iptables or any other tool you may be more comfortable with). I just realized that I could have done something like that later but you know in these situations where you just search for a solution to get out asap you don't always use the best one... Finally it didn't hurt to reset the peer but I would like to have a configuration in place that deals with such problems itself as far as possible without interaction, it was just by accident that I noticed this problem immediately and in another situation the I/O might have been hanging around for a lot longer time before someone finds the root cause ... probably causing ALL VMs residing on this setup to remount their filesystems r/o ... and that are just the moments I hate ;) regards, Felix