Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Wed, Jan 16, 2008 at 12:10:57AM +0100, Harald Rinker wrote: > Harald Rinker schrieb: > >Lars Ellenberg schrieb: > >>On Sat, Dec 29, 2007 at 03:18:32PM +0100, Lars Ellenberg wrote: > >> > >>>On Sat, Dec 29, 2007 at 10:44:17AM +0100, Harald Rinker wrote: > >>> > >>>>Hello Lars, > >>>> > >>>please avoid html mail (at least on mailing lists). > >>>and top posting is not a good habbit either. > >>> > >>> > >>>>I use Debian Etch Standard Kernel k713 2.6.18-4-amd64 and k641 > >>>>2.6.18-5-686 > >>>>and first i used drbd8 from backports now 8.0.8 from linbit website > >>>>compiled as > >>>>module with the kernel headers > >>>> > >>>in that case, it could be a bug in drbd > >>> somebody else should have noticed, there are lots of people using > >>> that kernel, including us, with varying configurations. > >>> > >> > >>hm. > >> > >>you DID hit a bug in drbd, > >>and no one (including us) did notice. > >> > >>that bug was only visible with protocol A, > >>and multipage bios. > >> > >>that means it would NOT show up with protocol B or C, > >>or with ext3, or when using any fs on top of lvm on top of drbd on > >>top of anything, > >>or when using any fs on top of drbd on top of lvm or md raid0/5/10. > >> > >>it would show up e.g. when using xfs on top of drbd > >>on top of bare sata/scsi or md raid1. > >> > >>workaround: see above, for when it does NOT show up. > >> > >>the fix is there: > >> http://git.drbd.org/?p=drbd-8.0.git;a=commitdiff;h=75a45802045fadaaaa926e58407726ace0317a0d > >> > >> http://git.drbd.org/?p=drbd-8.2.git;a=commitdiff;h=3a9e0f331315c487f79e32ff6e36b442d6d5369d > >> > >> > >>and will be in the next releases. yes, that means that we will likely > >>see yet an other release of drbd 8.2 within the next few days. > >> > >>embarrassing. > >> > >>cheers anyways, > >>and keep complaining! > >> > >> ;-> > >> > >> > Hi list, > > i have now new gb network cards use sync rate 5M using protocol B set > up node2 > and make drbdadm adjust daten > > /var/log/syslog say: > drbd0: Handshake successful: DRBD Network Protocol version 86 > Jan 15 23:35:48 k713 kernel: drbd0: Peer authenticated using 32 bytes of > 'sha256' HMAC > Jan 15 23:35:48 k713 kernel: drbd0: conn( WFConnection -> WFReportParams ) > Jan 15 23:35:48 k713 kernel: drbd0: Becoming sync target due to disk states. > Jan 15 23:35:48 k713 kernel: drbd0: Writing meta data super block now. > Jan 15 23:35:56 k713 kernel: drbd0: writing of bitmap took 1947 jiffies > Jan 15 23:35:56 k713 kernel: drbd0: 1499 GB (393203991 bits) marked > out-of-sync by on disk bit-map. > Jan 15 23:35:56 k713 kernel: drbd0: Writing meta data super block now. > Jan 15 23:35:56 k713 kernel: drbd0: peer( Unknown -> Primary ) conn( > WFReportParams -> WFBitMapT ) pdsk( DUnknown -> UpToDate ) > Jan 15 23:35:56 k713 kernel: drbd0: Writing meta data super block now. > > for about 5 Minutes it do nothing else and i must disconnect because the > load of node1 the primary on goes over 20 and nfs gives no answer > > drbdadm cstate daten tells WFBitMapT and no sync is running by cat > /proc/drbd > > dmesg on node2 (secondary) say: > drbd0: Handshake successful: DRBD Network Protocol version 86 > drbd0: Peer authenticated using 32 bytes of 'sha256' HMAC > drbd0: conn( WFConnection -> WFReportParams ) > drbd0: Becoming sync target due to disk states. > drbd0: Writing meta data super block now. > drbd0: writing of bitmap took 1947 jiffies > drbd0: 1499 GB (393203991 bits) marked out-of-sync by on disk bit-map. > drbd0: Writing meta data super block now. > drbd0: peer( Unknown -> Primary ) conn( WFReportParams -> WFBitMapT ) > pdsk( DUnknown -> UpToDate ) > drbd0: Writing meta data super block now. > eth2: no IPv6 routers present > drbd0: PingAck did not arrive in time. > drbd0: peer( Primary -> Unknown ) conn( WFBitMapT -> NetworkFailure ) > pdsk( UpToDate -> DUnknown ) > drbd0: asender terminated > drbd0: error receiving ReportBitMap, l: 4088! > drbd0: tl_clear() > drbd0: Connection closed > drbd0: Writing meta data super block now. > drbd0: conn( NetworkFailure -> Unconnected ) <- this one is because i > take down eth2 > > I don´t understand. On my tests bevor drbd starts syncing immediately > How long did wrote of Metadata work just because that was the last log message does not mean it was still doing that. look at the network traffic (tcpdump, iftop...), anything going on there? -- : Lars Ellenberg http://www.linbit.com : : DRBD/HA support and consulting sales at linbit.com : : LINBIT Information Technologies GmbH Tel +43-1-8178292-0 : : Vivenotgasse 48, A-1120 Vienna/Europe Fax +43-1-8178292-82 : __ please use the "List-Reply" function of your email client.