Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Dec 1998 09:17:30 -0800 (PST)
From:      Matthew Jacob <mjacob@feral.com>
To:        Tim Jones <tjones@estinc.com>
Cc:        Dag-Erling Smorgrav <des@flood.ping.uio.no>, cvs-all@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/sys mtio.h
Message-ID:  <Pine.LNX.4.04.9812210913450.32433-100000@feral-gw>
In-Reply-To: <367E7753.B8CAB53E@estinc.com>

next in thread | previous in thread | raw e-mail | index | archive | help

(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 <tjones@estinc.com> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.04.9812210913450.32433-100000>