Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!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: <1991Jun24.155738.17279@newshost.anu.edu.au>
Date: 24 Jun 91 15:57:38 GMT
References: <9850033@hpcpbla.HP.COM> <1991Jun21.200338.23597@newshost.anu.edu.au> <1991Jun23.072002.25736@odin.corp.sgi.com>
Sender: news@newshost.anu.edu.au
Organization: Computer Services Centre, Australian National University, Canberra, Australia.
Lines: 63

Dave,

Thanks for following up and confirming most of my summary and answering
the remaining questions.

In article <1991Jun23.072002.25736@odin.corp.sgi.com> olson@anchor.esd.sgi.com 
(Dave Olson) writes:

>| 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?

Yes, that was what I should have said.

>| 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.

Sorry, but I still don't get it. Why doesn't the kernel driver just
add the buffering layer in order to provide the lseek call? The DAT
drive I am using complains if you send it blocks that aren't a multiple
of 1K anyway (and reads them back padded to 1K). Surely anything that
has an lseek call of byte granuality is likely to use a buffer between
itself and the raw blocks on the physical device? My understanding is
that a "block" device adds the kernel cache buffers to a raw device
but the lseek is already available in the raw character device. It's
easy to have lseek on a disk device but not on a tty or lpt. Strikes
me it should also be easy to have lseek on a tape?

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