Date: Fri, 13 Nov 1998 09:11:49 -0800 (PST) From: Marc Slemko <marcs@znep.com> To: David Wolfskill <dhw@whistle.com> Cc: hackers@FreeBSD.ORG Subject: Re: dump(8) very slow Message-ID: <Pine.BSF.4.05.9811130909500.12077-100000@alive.znep.com> In-Reply-To: <199811131557.HAA03306@pau-amma.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 13 Nov 1998, David Wolfskill wrote: > >Date: Fri, 13 Nov 1998 15:46:51 +1100 > >From: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> > > >... > > >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9811130909500.12077-100000>