Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
It is my understanding that with GigE, you don't need a crossover cable. When I do direct server-server connections, I always use a straight through with Gigabit ports. My wife setup DRBD at her office the other week using a cross over cable and had nothing but problems. Changed it to straight through, and it worked fine. Not saying that is the problem - Just something that potentially can be changed. David Stefan Löfgren wrote: > This is also something similar to what I saw... > Using crossover cable. Trying to sync the resources caused a lot of > disconnects, > and it also got locked up in bitmap-transfer (what ever the name of > the state is)... > Also online verify failed after just a few %. So, switched to using > 100Mbit + switch I was able to > verify the complete disk. But after updating to 8.2.6rc1 made it > better... (but still not perfect as stated in another thread).. > > /Stefan > > > *---------- Original Message -----------* > From: "Dan Gahlinger" <dgahling at gmail.com> > To: "Tomasz Chmielewski" <mangoo at wpkg.org> > Cc: drbd-user at linbit.com > Sent: Mon, 19 May 2008 12:57:42 -0400 > Subject: Re: [DRBD-user] DRBD slow sync > > > speaking of slow sync, I have a similar issue. > > using a cross-over cable (2ft length) on gig interfaces, I can't set > rate to anything over 11M > > if I do, the units disconnect and go primary/unknown > unknown/secondary. no matter what I do. > > yet I can transfer data and files across the dedicated link at > really high speed. > > it's kind of crazy that a gig link interface can only do 11M in drbd. > > so I think it's related to this issue somehow. > > > > On Mon, May 19, 2008 at 10:19 AM, Tomasz Chmielewski > <mangoo at wpkg.org <mailto:mangoo at wpkg.org>> wrote: > > > > [WINDOWS-1252?]Anz(e Vidmar schrieb: > > > > > > hello list! > > > > I've setup a fresh install of DRBD + OCFS2 on the machine > with the following properties: > > > > OS: (Bluewhite64 12) Linux 2.6.23.9-2 > > ARCH: x86_64 > > CPU:8 x Intel(R) Xeon(R) CPU E5430 @ 2.66GHz > > eth0 = 1Gb > > DRBD version = 8.2.5 > > > > The problem is that DRBD sync in very slooooow, around > 315k/s. There is no way I can speed-up the process. The > storage with OCFS2 is 3.2T large and it's build on hardware > RAID5 + 1 spare. > > > > Here is what I've already did: > > > > - changed the UTP cable (cross and regular) > > - tried with kernel that has DRBD included in, and kernel + > DRBD module > > - I've test the data transfer directly on eth1 - the > transfer was normal aroung 75M/s, so the link between the > secondary (eth1) NIC's is ok > > - played with ethtool - I've setup the card to 100/1000M, > half/full duplex... No change > > - tweaking drbd.conf "net" parameters. No speed change at all. > > > > Anyone have any idea what might be causing the slow sync? Is > this normal for the 1st time sync? > > > > > > According to http://www.drbd.org/users-guide/re-drbdconf.html > the default rate is just 250 KB/s: > > > > rate rate > > > > To ensure a smooth operation of the application on top of > DRBD, it is possible to limit the bandwidth which may be used by > background synchronizations. The default is 250 KB/sec, the > default unit is KB/sec. Optional suffixes K, M, G are allowed. > > > > > > -- > > Tomasz Chmielewski > > http://wpkg.org <http://wpkg.org/> > > > > _______________________________________________ > > drbd-user mailing list > > drbd-user at lists.linbit.com <mailto:drbd-user at lists.linbit.com> > > http://lists.linbit.com/mailman/listinfo/drbd-user > > > > > *------- End of Original Message -------* > ------------------------------------------------------------------------ > > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20080519/42cd509f/attachment.htm>