From owner-cvs-all Mon Dec 21 09:18:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA21252 for cvs-all-outgoing; Mon, 21 Dec 1998 09:18:11 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from feral-gw.feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA21205 for ; Mon, 21 Dec 1998 09:18:06 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral-gw.feral.com (8.8.7/8.8.7) with ESMTP id JAA02226; Mon, 21 Dec 1998 09:17:31 -0800 Date: Mon, 21 Dec 1998 09:17:30 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Tim Jones cc: Dag-Erling Smorgrav , cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/sys mtio.h In-Reply-To: <367E7753.B8CAB53E@estinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk (gee- I missed the front of this email exchange... too much mail) On Mon, 21 Dec 1998, Tim Jones wrote: > Dag-Erling Smorgrav wrote: > > > > Tim Jones writes: > > > So that everyone understands, the next version of BRu for Linux will > > > offer Quick File Access. This means that the user can say "Restore > > > mydatafile.dbf" and BRU will fast forward the tape to the appropriate > > > logical block address and restore the file. This means a file 2GB deep > > > on a DAT tape will restore in 30 seconds, instead of 45 minutes. > > > > Will this also speed up 'mt [fb]s[fr]'? > > Hi DES, > > This will be dependent on the tape drive used. If a 4mm DDS or 8mm > drive, then it will definitely speed things up as the command to > implement the motion command (SPACE - command 0x11 or (on older Archive > and Wangtek 1/4") SEEK BLOCK - command 0x0C) use the drive's high speed > wind functions. > > However, my tests here indicate that the 'mt fsf' when applied to my > DDS-2 HP drive works as it should (takes around 15 seconds to get in > 400MB or so). Be aware that linear tape drives (1/4", Travan, et al) > will always be slower than this since seek speed is only slightly faster > than normal read speed. For example, the new NS-8/NS-20 drives spin > tape at 100ips for normal read/write, but the fast seek speed is only > 120ips. > The drives where this makes a really *substantial* are the high end drives, like STK Redwoods and IBM 3590s. That's for forward spacing. The other case which is less evident is the random positioning case. It's only if you *really* are sure where to to space filemarks and records to that random positioning can match fast locate. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message