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 failover. 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. Best, Whit