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 primary? 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 starts > 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 http://lists.linbit.com/mailman/listinfo/drbd-user