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