From owner-freebsd-hackers Fri Nov 13 09:15:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA03297 for freebsd-hackers-outgoing; Fri, 13 Nov 1998 09:15:39 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alive.znep.com (207-178-54-226.go2net.com [207.178.54.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA03280 for ; Fri, 13 Nov 1998 09:15:35 -0800 (PST) (envelope-from marcs@znep.com) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.1/8.9.1) with ESMTP id JAA25948; Fri, 13 Nov 1998 09:11:49 -0800 (PST) (envelope-from marcs@znep.com) Date: Fri, 13 Nov 1998 09:11:49 -0800 (PST) From: Marc Slemko To: David Wolfskill cc: hackers@FreeBSD.ORG Subject: Re: dump(8) very slow In-Reply-To: <199811131557.HAA03306@pau-amma.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 13 Nov 1998, David Wolfskill wrote: > >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. Right, or you can just pipe dump through something like "team" which will buffer it. Really, that is the biggest problem I find with dump. On many systems, it isn't that it can't read quickly enough to fill the tape it is that there isn't enough buffering to let it do so smoothly, and when the tape isn't streaming it isn't a happy camper. You do, however, lose some things like reliable end of tape detection. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message