Xref: utzoo comp.periphs:3456 comp.sys.sgi:8209 comp.periphs.scsi:1863
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!uunet!brunix!sgf
From: sgf@cs.brown.edu (Sam Fulcomer)
Newsgroups: comp.periphs,comp.sys.sgi,comp.periphs.scsi
Subject: Re: exabyte record size limit
Message-ID: <64513@brunix.UUCP>
Date: 11 Feb 91 20:34:27 GMT
References: <1991Feb8.154343.11054@helios.physics.utoronto.ca> <52691@sequent.UUCP>
Sender: news@brunix.UUCP
Reply-To: sgf@cs.brown.edu (Sam Fulcomer)
Organization: Brown University Department of Computer Science
Lines: 42

In article <52691@sequent.UUCP> norsk@eng3.UUCP (Doug Thompson) writes:
>In article <1991Feb8.154343.11054@helios.physics.utoronto.ca> sysmark@physics.utoronto.ca (Mark Bartelt) writes:
>>I have an exabyte drive (from Dilog) on a 4D25.  When I recently upgraded
>>to IRIX 3.3.1, I was pleased to find the /dev/{r}mt/tps*v devices:  It's
>>nice to finally be able to read/write arbitrary-length tape records!

Well, some people have it mostly right. The 8200 has a 256k data buffer.
The maximum logical block length for fixed or variable block modes is 240k.
the physical block length is 1024 bytes. The data buffer circuitry 
adds block address and tag information in the data buffer, hence the 240k
limit.

The 8200 format writes 8 physical blocks of data (1024 bytes each, with 400 
bytes ECC and 16 bytes address) during each physical write operation. 
The result is one diagonal stripe or "track" on the tape. (Note that this is 
ALWAYS the case.) so there isn't really an arbitrary-length record on the
tape in the sense that there is on  the typical 1/2" (capacity doesn't
increase with increased block size past 1k in 1k multiples , and there's 
no "record mark" or inter-record gap on the tape, since gaps can occur).

The most inefficient use possible for the 8200 is with a block length of 1 
and unbuffered write mode (when issuing a write operation in fixed block
mode with a transfer size of only one block). This will yield a stripe
consisting of 1 physical block containing user data (a 1024 byte physical
block containing a 1-byte logical block followed by pad bytes) and 7
gap blocks. The next 8k stripe will consist of 8 more gap blocks, which 
serve as a marker for the firmware on a reposition for the correct
location to continue writing. Thus, where you could have had 16k of data
on the tape, you only have 1 byte. 

I assume that most sensible drivers use buffered mode writes, however.
In buffered mode writes the data buffer fills up to a predetermined
point before the drive actually writes the data to tape. The predetermined
point is called the "write motion threshold" and defaults to 240k.
At this point the write circuitry begins transferring data to the tape.
I presume that the reason it defaults to 240k is to allow it to
determine whether a block's worth of data has been transferred before 
writing.

The most efficient use of the tape can be made by using a logical block
size (with buffered and either fixed or variable mode) which is always 
some multiple of 1k and by keeping the buffer from emptying.