Date: Mon, 16 Nov 1998 11:24:32 +1100 From: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> To: hackers@FreeBSD.ORG Subject: Re: dump(8) very slow Message-ID: <98Nov16.112411est.40348@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
I wrote: >Unfortunately, dump(8) is distinctly sub-optimal as far as reading the >disk is concerned..... David Wolfskill <dhw@whistle.com> wrote: >Well, what I do, in large part to deal with this, is have amanda run >dump for me. Amanda definitely addresses the `how to backup a network' problem, but it doesn't address dump's underlying poor performance. Marc Slemko <marcs@znep.com> wrote: >Right, or you can just pipe dump through something like "team" which will >buffer it. There's also `buffer', which I use at home (primarily because it was the first thing I came across that did what I wanted). It uses a single reader process and a single writer process, sharing a SysV shared memory segment and communicating via SysV semaphores. I agree that decoupling the disk reading from the tape writing is beneficial. My problem is that the _average_ disk reading speed is too slow to keep the tapes streaming. In this environment, memory- based utilities like team and buffer will (at best) just extend the time between streaming pauses. Amanda does get around this problem, but needs enough disk space to cache the entire dump - which I can't currently afford. Speeding up dump should also shorten the duration of backups - which can hardly be bad. Someone else (I accidently deleted the reference) commented that the drive should manage to glue together multiple reads so that the degradation isn't as serious. I did a few tests (using dd) and found that for IDE drives there was a significant improvement between 8K and 16K, but going above 16K didn't help. For SCSI (a Barracuda on a slow/narrow adapter), there was little improvement over 8K with only 1 thread accessing the drive. Once you go to multiple threads, the more data you can read at a time, the better. At this stage, I might have a closer look at what is involved in changing dump. Or at least instrumenting it to see what impact the changes would have on a couple of real filesystems. Peter 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?98Nov16.112411est.40348>