From owner-freebsd-hackers Fri Nov 13 07:59:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA22994 for freebsd-hackers-outgoing; Fri, 13 Nov 1998 07:59:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pau-amma.whistle.com (s205m64.whistle.com [207.76.205.64]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA22989 for ; Fri, 13 Nov 1998 07:59:35 -0800 (PST) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.8.8/8.8.7) id HAA03306 for hackers@FreeBSD.ORG; Fri, 13 Nov 1998 07:57:08 -0800 (PST) (envelope-from dhw) Date: Fri, 13 Nov 1998 07:57:08 -0800 (PST) From: David Wolfskill Message-Id: <199811131557.HAA03306@pau-amma.whistle.com> To: hackers@FreeBSD.ORG Subject: Re: dump(8) very slow In-Reply-To: <98Nov13.154625est.40323@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Fri, 13 Nov 1998 15:46:51 +1100 >From: Peter Jeremy >... >Unfortunately, dump(8) is distinctly sub-optimal as far as reading the >disk is concerned..... >... >Is this approach worth the effort? I suspect this depends on how well >associated sequential blocks of inodes correlate to associated groups >of data blocks on disk - I don't know the answer to this. >... Well, what I do, in large part to deal with this, is have amanda run dump for me. (At work. At home, I let dump write directly to tape, but so far, I'm nowhere near the point of needing the performance gains, and I'm unwilling to use a separate tape cartridge for each day's backups.) One of the things that amanda will do (given a chance) is send dump's output to a pipeline (that may involve compressing the image and/or sending it to a different machine, which has a tape drive), and thence to a "holding disk" -- which basically acts as a largish speed-matching buffer. Thus, it allows multiple dump processes to be running at the same time; as soon as a dump image is finished, that image is queued for a separate process to write it to tape. This de-coupling of the reading that dump does, vs. the writing to tape, allows for significant speed-ups (among other things). So I'd be hard-pressed to think that the effort you describe is likely to be worth it, given that amanda is free, and the concept of the de-coupling should be somewhat easier to implement than what you describe, even if you don't want to run amanda. Maybe it would be worth it for some, though.... david -- David Wolfskill UNIX System Administrator dhw@whistle.com voice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message