From owner-freebsd-questions Fri Oct 29 9: 8:18 1999 Delivered-To: freebsd-questions@freebsd.org Received: from yana.lemis.com (yana.lemis.com [192.109.197.140]) by hub.freebsd.org (Postfix) with ESMTP id 4F89A157F8 for ; Fri, 29 Oct 1999 09:08:06 -0700 (PDT) (envelope-from grog@lemis.com) Received: from mojave.worldwide.lemis.com ([199.103.141.157]) by yana.lemis.com (8.8.8/8.8.8) with ESMTP id BAA23782 for ; Sat, 30 Oct 1999 01:38:01 +0930 (CST) (envelope-from grog@lemis.com) Message-ID: <19991025105358.42830@mojave.worldwide.lemis.com> Date: Mon, 25 Oct 1999 10:53:58 -0600 From: Greg Lehey To: Christian Weisgerber , freebsd-questions@freebsd.org Subject: Re: Why is restore so much slower than dump? References: <7uv4u4$13f1$1@bigeye.rhein-neckar.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <7uv4u4$13f1$1@bigeye.rhein-neckar.de>; from Christian Weisgerber on Sun, Oct 24, 1999 at 04:26:12PM +0200 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sunday, 24 October 1999 at 16:26:12 +0200, Christian Weisgerber wrote: > GWIS - Dan Roberts wrote: > >> I'm using a DDS-3 drive to backup files using rdump between two private >> 100Mbit ports on a switched network. Dumps are fairly quick, but now I'm >> trying to restore a filesystem and it's going deathly slow. > > I've had also the opportunity to do a full restore this weekend-- > after I lost a good chunk of my SCSI periphery to a faulty power > cable that insidiously reversed the 5/12V leads--and I haven't been > too happy with the speed either. Part of the blame goes to my old > tape drive (250kB/s max), but even that didn't run continuously > for part of the restore (probably /usr/src or /usr/ports), so a > faster drive wouldn't have been any help there. > >> It's obvious from the slowly flickering drive activity and nic >> card lights that the efficiency of this operation could be greatly >> improved. Does anyone know what the problem is, and if there is >> anything I can do about it? > > The problem is pretty obviously directory trees with lots of small > files that require a disproportional amount of seeking by the hard > disk. Another possibility is that the drive needs cleaning and is performing too many retries. You can check this by doing: dd if=/dev/nrst0 of=/dev/null bs=10b That should be fast (about 700 kB/s with compression, I believe). If things are still going slowly, you should check the drive. Clean it first; if that doesn't work, get it serviced before you start losing data. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message