Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!anchor!olson
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.periphs.scsi
Subject: Re: Random Access DAT
Message-ID: <1991Jun23.072002.25736@odin.corp.sgi.com>
Date: 23 Jun 91 07:20:02 GMT
References: <1991Jun14.211246.4340@newshost.anu.edu.au> <9850033@hpcpbla.HP.COM> <1991Jun21.200338.23597@newshost.anu.edu.au>
Sender: news@odin.corp.sgi.com (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 74

In <1991Jun21.200338.23597@newshost.anu.edu.au> cmf851@anu.oz.au (Albert Langer) writes:

| Thanks to Steve Jermin, Kevin Jones and Roy Neese for various answers.
| 
| My summary would be as follows:
| 
| 1. Effective use of the high speed random access tape drive mechanism
| can be achieved by just using mt and the non-rewind device. One can
| use mt to skip backwards or forwards by literally hundreds or thousands
| of filemarks and it will do so at full speed.

Yes, this works amazingly quickly.  The first time I tried it,
I thought the driver or firmware was broken, until I verified
it on the SCSI analyzer.

| 2. It is unlikely that the ordinary seek ioctl mechanism will be
| properly implemented on current unix drivers.

There is no 'ordinary' seek ioctl, that I know of.  IRIX 4.0
on the SGI machines has added an MTSEEK ioctl that uses the
SCSI 1 seekblock cmd on scsi 1 drives, and the locate command on
SCSI 2 drives like the Python DAT.  Perhaps from your discussion
below, you were thinking of the lseek system call?

| 3. SCSI DAT drives could be used for audio input and output with a
| certain amount of difficulty.

The main problem is to define a data format, and to modify the
DAT firmware to use that format; most of the DDS drives seem
to have all the hardware necessary to do this, unlike the
CDROM drives.  This is not trivial, but not technically impossible.

| 5. If I use the script provided to put say 500 directories onto tape
| in one session and then for a year of 365 days I keep rewinding to the
| start and spacing out to the end and then appending another 10 directories
| to the tape (so I end up with about 4,150 cpio files on tape, each
| separated by a filemark), can I later decide to truncate to say 3000 and
| rewrite everything after that? i.e. I would rewind and space out to file
| 3000 and then just start appending files as usual - losing whatever was
| on the tape after file 3000 but retaining everything before then.

Yes, the DDS DAT format allows overwrite, unlike QIC drives; it
just doesn't allow update in place.  The new EOD will be wherever
you stop writing.

| 6. I don't understand why different interpretations of SCSI and DDS etc
| should prevent unix drivers from properly implementing the seek ioctl
| on the raw tape device. All I want is the unix semantics of a file of
| bytes which I can position to any arbitrary byte within (and if I try
| to seek past the end of file tape mark that is an error). If the
| implementations are different that might cause media exchange problems
| but I would still expect to be able to seek forward or backwards on
| the same machine at high speed. This should be a separate facility to
| spacing forward or backwards to an end of file tapemark.

Arbitrary byte seeks won't work, unless you use a blocksize of 1
byte, which actually works, at least on IRIX 4.0; you could have
problems with some drivers.  All of the space block, seek block,
and locate commands work in terms of blocks.   Using very small
block sizes will waste tape (not as much as 8mm, but still a fair
amount), and reduce data rates considerably.

If you are willing to live with arbitrary block offsets, then 
there should be no problem, and high speed seek (to block, fm, or
setmark) works fine, and should work on any driver that implements
the capability.  Finer buffering can be done in the user
program.  Some vendors may implement 'block' (much like the block
disk interface), rather than 'raw' tape, but not all (IRIX doesn't).

As has been discussed in some of the other comp.unix* newsgroups,
most tape drives make it impossible to imitate byte stream semantics
without adding a buffering layer (and updates in place just won't work
at all).  You also need to give up variable blocksizes to make this
work at all.