Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!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: <1991Jun25.072303.27866@odin.corp.sgi.com>
Date: 25 Jun 91 07:23:03 GMT
References: <9850033@hpcpbla.HP.COM> <1991Jun21.200338.23597@newshost.anu.edu.au> <1991Jun23.072002.25736@odin.corp.sgi.com> <1991Jun24.155738.17279@newshost.anu.edu.au>
Sender: news@odin.corp.sgi.com (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 36

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

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

My original point is that many tape drivers do NOT implement lseek,
and thus the buffering layer doesn't exist.  Confining lseek to
non-variable blocked tapes, and requiring the offset on entry to the
driver to be a multiple of the block size; then doing the required
space block or locate command automatically isn't that hard, but
doesn't meet your requirements.  You would also run into a problem
once you got past 2Gb in capacity, since on most 32 bit systems,
off_t (lseek's 3rd arg type) is a signed 31 bit number...

'Just' adding the buffering layer is non-trivial, unless
it exactly matches the semantics of the existing block buffering
layer (disk drives).  Unfortunately, tape does not.  If you
were willing to live with a readonly block interface, and
write the tape some other way, it would be much easier.

One of the side effects of the block interface is asynchronous
writes; which make it rather hard to report the errors that would
be likely to occur, since one can't update in place with DDS DAT.

Writing a different buffering system, unique to the tape driver
would itself be a significant amount of work, for very little
gain, although it certainly isn't impossible.  It still wouldn't
completely match the byte stream model.