Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2004-05-19 12:36:33 +0400 \ Eugene Crosser: > On Mon, 2004-05-17 at 17:15, Eugene Crosser wrote: > > This is today's CVS drbd 0.7_pre7 > > It may be related to DRBD or Jan's recent changes in ext3. > > After a couple switchovers of primary and secondary, right when nfsa1 > > was booting, primary nfsa2 got filesystem panic (which did not actually > > halted the system but this is another story). > > > > May 17 16:49:18 nfsa2.mail.back kernel: tg3: eth1: Link is up at 1000 Mbps, full duplex. > > May 17 16:49:18 nfsa2.mail.back kernel: tg3: eth1: Flow control is on for TX and on for RX. > > May 17 16:49:33 nfsa2.mail.back kernel: EXT3-fs error (device drbd0): ext3_free_blocks: bit already cleared for block 43658531 > > May 17 16:49:33 nfsa2.mail.back kernel: Kernel panic: EXT3-fs (device drbd0): panic forced after error > > I am not 100% sure but quite probably this was related to the other > problem that I reported later, when synctarget thinks that it is OK but > syncsource does not complete. I mean, the corruption happend after I > did a switchover when the nodes where in such inconsistent state. yes, sound reasonable. problem identified meanwhile, solution seems either brutal or not that simple. if you try cvs co from today, it should reduce the race (bitmap being modified while beeing exchanged), but it is the brutal solution, so IO may hang for some seconds while the connection handshake is done... and it is not even strictly correct, since theoretically there still is a race :( > Speaking of the filesystem and quota, it looks quite stable now (running > torture tests for 24h, goes smoothly so far). good :)