Date: Mon, 19 Nov 2001 20:01:00 -0600 From: Christopher Farley <chris@northernbrewer.com> To: Greg Lehey <grog@FreeBSD.org> Cc: questions@freebsd.org Subject: Re: Slow restores on a DLT4000 Message-ID: <20011119200058.B92015@northernbrewer.com> In-Reply-To: <20011120115256.H76318@monorchid.lemis.com>; from grog@FreeBSD.org on Tue, Nov 20, 2001 at 11:52:56AM %2B1030 References: <20011119150711.A7781@northernbrewer.com> <20011120115256.H76318@monorchid.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011119200058.B92015>