[DRBD-user] drbd turned on me, and bit my hand this morn

Lars Ellenberg Lars.Ellenberg at linbit.com
Sat Dec 10 14:57:01 CET 2005

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


/ 2005-12-10 07:39:34 -0500
\ Brad Barnett:
> 
> 
> 
> 
> Ok, my drbd rebuild is complete, and I can do some testing this weekend at
> specific planned times.
> 
> Before I do, I'd like to ask a few questions.  I might as well try to tune
> drbd as best as I can, beforehand. ;)
> 
> Anyhow, as far as I can tell, the syncer seems to be for the sync process
> ... and not normal data transfer between the two drbd nodes?  I ask,
> because I actually had to turn off my full sync process during the day, as
> nfs access dropped to approximately 1/50th the speed with it on.
> 
> Is the sync process supposed to "give way" to the normal data updates
> between the nodes?  Or, during a full sync, does drbd store local changes
> on the primary.. and just ignore sending anything to the secondary?

Syncer access and application writes are concurrent.
They are not prioritized. This is on the wishlist, though.
You "give way" by setting the sync rate to something lower than your
actual bandwith, thereby "reserving" the rest of the bandwidth for your
applications.

BTW, you won't see a Full Sync with drbd 0.7 and later, except for the
initial one, or in case one of the lower level storages gets physically
replaced, and you _request_ a full sync again by invalidating that device.

> If so, why was my access so slow during that full sync?  I tried reducing
> my sync from 700000k to 250000k, but I saw no difference in

Note that we are storage guys, not network guys.
So think storage.
This rate is given in Byte, not Bit.
I seriously doubt your hardware can
do sustained 250 Mega Byte transfer rate.

> syncer rate/performance.  I have a crossover cable between two gigabit
> network devices.. and dmesg as well as ethtool confirms this.
> 
> Any suggests for better usage while sync is happening.. or ways to tune
> this baby?

-- 
: 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.



More information about the drbd-user mailing list