[DRBD-user] Suggestion for DRBD User's Guide

Whit Blauvelt whit+drbd at transpect.com
Wed Mar 12 16:22:38 CET 2008

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

On Tue, Mar 11, 2008 at 09:01:50PM +0100, Florian Haas wrote:

> > My initial impression, having not seen this complete yet, is that this is
> > running a lot slower than, say, rsync would in duplicating the same amount
> > of data. Doubtless drbd has more to do. Anyway, it would be helpful if the
> > manual gave a rough formula for guestimating sync time.
> Added to the to-do list. Not sure whether it will be in the changeset for next 
> week though.

Here's an additional question the manual might answer: Are the subsequent
operations as slow as the initial sync? Or do they runs at something closer
to normal file transfer speed? In our case what I'm trying to test it for is
a 60 gig partition. It's been running the initial sync for a day, and looks
to have another day to go. This is between one gig NICs, between top-end HP
boxes. It will be really useful if drbd is capable in this circumstance. But
if putting a new 2 gig file onto the primary device results in a sync this
slow - it's roughly taking about an hour to sync a single gig on the initial
pass here - then drbd makes no sense compared to running rsync at regular
intervals. On the other hand, if drbd works in something close to real time,
it will be much better than an rsync strategy - this is data in financial
services; being more current than rsync could manage would be of value in a

Since I won't be able to test operational transfer speed in this setup until
tomorrow, I just don't know. But the manual should tell me, before I get
myself into a situation where I'm waiting for a couple of days just to do
the feasibility test. Is drbd useful only for very small devices or devices
in minimal use? I'm guessing not, since I've seen no upfront warning that
this is the case.

Your manual is excellent so far, by the way - much better than most.


More information about the drbd-user mailing list