Newsgroups: comp.periphs.scsi
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!munnari.oz.au!manuel!cmf851
From: cmf851@anu.oz.au (Albert Langer)
Subject: Re: Random Access DAT
Message-ID: <1991Jun25.165330.28323@newshost.anu.edu.au>
Sender: news@newshost.anu.edu.au
Organization: Computer Services Centre, Australian National University, Canberra, Australia.
References: <1991Jun23.072002.25736@odin.corp.sgi.com> <1991Jun24.155738.17279@newshost.anu.edu.au> <1991Jun25.072303.27866@odin.corp.sgi.com>
Date: Tue, 25 Jun 91 16:53:30 GMT

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

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

I could certainly live with a readonly block interface between
filemarks, especially since the tape has to be rewritten from
a filemark anyway. I could also live with a 2GB file size limit
(again between filemarks) since quite a few other pointers would
break on anything larger anyway (apart from current tape
capacity being smaller than 2GB for DAT).

However I do now understand, from your explanation, that adding
lseek is not as trivial as I thought, and since the filemark
mechanism only occupies 4bytes and does not slow things down I
guess it will do for most applications (including the one I had
in mind - just storing thousands of files offline for retrieval
in batches or on a delay of 12 seconds or so rewind time) so
that explains why normal unix drivers may not include it.

I still think that since it is relatively easy for just a
readonly block interface, even though non-trivial, and since
that is all that could ever be possible for DDS, the unix
driver SHOULD implement lseek. One possible application would
be for a huge hashed database, prepared online, to be dumped
to tape and then be accessible with a 12 second or so delay,
or in batches. But I guess anybody doing that can just go
ahead and write the driver too.

Anyway, ALL my questions are answered now. Thanks to all who
gave advice... it's appreciated.

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