From owner-freebsd-questions Mon Nov 19 18: 1:12 2001 Delivered-To: freebsd-questions@freebsd.org Received: from mail.nbrewer.com (sparge.nbrewer.com [208.42.68.70]) by hub.freebsd.org (Postfix) with ESMTP id 85A2337B416; Mon, 19 Nov 2001 18:01:08 -0800 (PST) Received: by mail.nbrewer.com (Postfix, from userid 1001) id C48B74B7195; Mon, 19 Nov 2001 20:01:01 -0600 (CST) Date: Mon, 19 Nov 2001 20:01:00 -0600 From: Christopher Farley To: Greg Lehey Cc: questions@freebsd.org Subject: Re: Slow restores on a DLT4000 Message-ID: <20011119200058.B92015@northernbrewer.com> Mail-Followup-To: Christopher Farley , Greg Lehey , questions@freebsd.org References: <20011119150711.A7781@northernbrewer.com> <20011120115256.H76318@monorchid.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011120115256.H76318@monorchid.lemis.com>; from grog@FreeBSD.org on Tue, Nov 20, 2001 at 11:52:56AM +1030 Organization: Northern Brewer, St. Paul, MN Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greg Lehey (grog@FreeBSD.org) wrote: > On Monday, 19 November 2001 at 15:07:13 -0600, Christopher Farley wrote: > > I am a new owner of a pair of DLT4000 drives. I've been testing them > > using dump and restore. > > > > I get fairly good throughput on dumps; about 1.6 megs/second, which > > seems similar to 'average' expectations that have been published. > > During a dump, the drive does not stream, but runs, stops, rewinds, > > runs, stops, rewinds... My thinking is that the tape drive is able to > > write to a tape faster than my platters can provide the bits. > > Hmm. I have one of these drives too, and I see data rates of up to 3 > MB/s. Are you using compression? The drive's hardware compression is enabled. My drives are not SCSI, but IDE drives on an ATA/100 bus. With DAT, it's been my experience that hardware compression speeds things up significantly. I have not yet tried benchmarking my DLT4000 with hw compression off, but I plan to. > > Restoring data off a level 0 dump takes about twice as long as the dump > > itself, and it also fails to stream. > > This is almost certainly due to the metadata updates. Soft updates > will help, but basically the disk is becoming the bottleneck. Oh yeah, soft updates are not enabled, but I plan to fix that soon. And a `restore -N` (with no disk writes -- don't know about metadata updates) takes just as long as a regular restore. > > Also, it takes just as long to retrieve a few files off of a dump as > > it does to restore an entire dump. > > Well, I suspect it seems that way. In fact, it should be able to > stream up to where it finds the files, so it should be a little > faster. Throughout the restore it reads the tape, stops, rewinds, starts up again... It reads for maybe 5-6 seconds max. This occurs on both of my DLT4000s. It takes about 4 hours to get one file off the end of a 20 Gig level 0 dump. > > It seems like the drive simply reads the tape sequentially, and if > > it sees a file I've marked, it writes it to the disk. Consequently, > > if the file is at the end of the tape, it will take 4 hours to find > > the file on a 20 Gig dump. > > Yes, that's correct. The obvious choice here is to make several > smaller dumps and then search to the beginning of the dump, which is > much faster (a minute or two maximum). I've been doing my dump/restores off of a very large filesystem, and I plan to reconfigure my setup to make smaller slices. Forutnately, I've got a nice tape drive to help me do this... -- Christopher Farley www.northernbrewer.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message