Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!uunet!munnari.oz.au!manuel!cmf851
From: cmf851@anu.oz.au (Albert Langer)
Newsgroups: comp.periphs.scsi
Subject: Re: Random Access DAT
Message-ID: <1991Jun21.200338.23597@newshost.anu.edu.au>
Date: 21 Jun 91 20:03:38 GMT
References: <1991Jun14.211246.4340@newshost.anu.edu.au> <9850033@hpcpbla.HP.COM>
Sender: news@newshost.anu.edu.au
Organization: Computer Services Centre, Australian National University, Canberra, Australia.
Lines: 46

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.

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

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

4. It would be impractical to use audio DAT for SCSI computer purposes
as that would amount to designing a SCSI DAT drive controller just as
the existing suppliers do.

A couple of supplementary questions:

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.

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.

Anyway, thanks again. Albert


--
Opinions disclaimed (Authoritative answer from opinion server)
Header reply address wrong. Use cmf851@csc2.anu.edu.au