[DRBD-user] [OT] rsync issues [Was Re: Read performance?]

David Masover ninja at slaphack.com
Tue Jun 5 20:51:17 CEST 2007

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

On Tuesday 05 June 2007 09:41:44 Leroy van Logchem wrote:
> > But the "queue" directory doesn't even exist for DRBD:
> >
> > root at norton:~# ls /sys/block/drbd0/
> > dev  holders  range  removable  size  slaves  stat  subsystem  uevent
> > root at norton:~#
> Try grep -i sched /var/log/dmesg.

Tells me what's compiled in, and what's the default scheduler (it's deadline, 

> On another note: You might want to try ssync instead of rsync. It starts
> without building the filelist.

Very nice. I might have done it that way if I had to do it over again.

On Tuesday 05 June 2007 10:25:04 Ross S. W. Walker wrote:
> > generally I recommend deadline.
> > for your situation (high latency network link) I suggest
> > small nr_requests.
> > whether or not that is the real problem, I cannot tell, this has only
> > been an educated guess.
> Actually anticipatory might be better here as it will get the
> read requests down first as the #1 slow-down are write requests.

Well, it looks like it's set to deadline now, which is also the default for 
the box. Anticipatory might be better, I'll remember that if I need it...

> If the link is high-latency I would seriously look into using
> asynchronous replication in an active-passive setup, then use
> a network file system with local-cache backing store for sharing
> the storage... I believe Solaris has NFS caching backing store.

Erm...  If I understood what you said, I'm not sure I like that way.

The whole point of DRBD and replication is that if the office burns down, we 
can pick up the box from offsite, physically drive it into the office, and 
bring it up as a DRBD primary, then use BackupPC to restore as if we had the 
original backup server intact.

I don't like the idea of using a cache for that, and I really don't like the 
idea of asynchronous replication here, unless it's done entirely in-order. If 
the primary goes down, the FS image on the secondary must be consistent.

In any case, thanks for all your help, and in the end, the problem is solved 
by brute force.

It's only the initial backups which were frustrating, as they took days, and 
any attempt to, say, edit a config file that was stored on the DRBD device 
was almost impossible (I was deliberately disconnecting them just to get vim 
to open; I always hated the vim swapfile on slow media).

Nowdays, even with synchronous replication (over a slow DSL link, over a VPN), 
the whole backup process takes a little under an hour, mostly thanks to 
BackupPC's pooling and compression. Since this happens overnight, I'm not 
even there to notice slow reads.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20070605/1b4b0acb/attachment.pgp>

More information about the drbd-user mailing list