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, btw). > 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>