[DRBD-user] Kernel panic while syncing

JMWorld - Dpto. Técnico updeits at jmworld.es
Fri May 5 11:14:32 CEST 2006

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

Thank you for the response.
Do you mean that the only way to avoid drbd to raise a kernel panic and
loosing control over the machin is to start the node with updated data as
Since it should be the first syncing... is there any way to force a node to
be primary and to force data to be de valid and updated so secondary thought
it is inconsistent and starts performing data download from primary?

Thank you very much
JMWorld sii SL

-----Mensaje original-----
De: drbd-user-bounces at lists.linbit.com
[mailto:drbd-user-bounces at lists.linbit.com]En nombre de Lars Ellenberg
Enviado el: viernes, 05 de mayo de 2006 10:57
Para: drbd-user at lists.linbit.com
Asunto: Re: [DRBD-user] Kernel panic while syncing

/ 2006-05-04 11:16:30 +0200
\ JMWorld - Dpto. Técnico:
> Kernel panic
> While syncing Primary shows next dump but about a minute before sync
> we lost the connection with primary.
> System is running sarge-backports debian kernel 2.6.15 for i686 with SMP
> support but with only one processor.
> Is there any kernel compilation requirement to succesfully run drbd???
> Servers are connected throught vtund tun tunnel with compression level 9
> (zlib) and mtu=1450
> People at datacenter tell us that console shows something like:
> drdb: sorry ...
> kernel panic
> not syncing:drdb0: Sorry I have no access to good data anymore

> cat /proc/drbd:
> version: 0.7.18 (api:78/proto:74)
> SVN Revision: 2176 build by root at raimunda, 2006-05-03 12:54:34
>  0: cs:SyncTarget st:Primary/Secondary ld:Inconsistent

so you are Primary, but sync target. meaning: your local copy of the
data is bad, and gets overwritten by the good copy from the peer.

> May  4 09:47:33 raimunda kernel: NETDEV WATCHDOG: eth0: transmit timed out
> May  4 09:47:33 raimunda kernel: eth0: Transmit timeout, status 00000000

then you lose connectivity.

so now you have a primary, without data (the good data is on the peer,
which is no longer reachable).
drbd decides to panic, the assumption beeing:
  either the peer is dead. then there is no data
  anymore, and there is no point in waiting for it.
  or the peer is alive, but the link is dead.
  if we panic, we normally die, all processes die,
  heartbeat on the other node sees that this node is dead,
  and take over.

this is the reason why you should avoid to make a SyncTarget Primary.

: Lars Ellenberg                                  Tel +43-1-8178292-0  :
: LINBIT Information Technologies GmbH            Fax +43-1-8178292-82 :
: Schoenbrunner Str. 244, A-1120 Vienna/Europe   http://www.linbit.com :
please use the "List-Reply" function of your email client.
drbd-user mailing list
drbd-user at lists.linbit.com

More information about the drbd-user mailing list