Xref: utzoo comp.periphs:3446 comp.sys.sgi:8185 comp.periphs.scsi:1846
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!ames!uhccux!uhheph.phys.hawaii.edu!ralph
From: ralph@uhheph.phys.hawaii.edu (Ralph Becker-Szendy)
Newsgroups: comp.periphs,comp.sys.sgi,comp.periphs.scsi
Subject: Re: exabyte record size limit
Message-ID: <11372@uhccux.uhcc.Hawaii.Edu>
Date: 9 Feb 91 03:56:08 GMT
References: <1991Feb8.154343.11054@helios.physics.utoronto.ca>
Sender: news@uhccux.uhcc.Hawaii.Edu
Followup-To: comp.periphs
Organization: U of Hawaii High Energy Physics
Lines: 47

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!
>
>However, I've found that there's a record size limit of 240k bytes.  Any
>attempts to write records longer than that return EINVAL.  Is this just a
>misfeature of the IRIX tape driver, or is it a characteristic of exabyte
>drives, or a limit (general, or SGI's) on the size of SCSI transfers, or
>what?  And, whichever, why was 240k chosen?
>
>For that matter, should I even care?  Back in ancient times, when all we
>had were half-inch drives at, say, 800 or 1600 bpi, it was worth writing
>data in blocks as large as possible, to minimize the amount of tape that
>was wasted in inter-record gaps.  How, exactly, do exabytes separate the
>physical records?  And how much tape does that information use, compared
>with the length of an N-byte record?
>
>Mark Bartelt                                                416/978-5619
>Canadian Institute for                          sysmark@cita.toronto.edu
>Theoretical Astrophysics                        sysmark@cita.utoronto.ca

First of all, the drive writes 8kB "blocks". The term to use is probably
"diagonal strip of data", since each pass of the helical scan head over the
tape makes a diagonal strip. As far as I understand the little bit of 
documentation Summus gave us with our drives (which I can't find anywhere 
right now) each physical stripe contains an 8kB block of user data, and an 
extra ~2kB of ECC data, but don't quote me on that. If you write records less 
then 8Kb (or less than a multiple of 8kB) the rest of the block will be 
wasted. Therefore writing 1kB blocks is a real dumb idea. If you stick to 
records of 8kB or multiples (maybe for safety reasons shave a few bytes off 
that) the space should be used maximally efficient. There is no inter-record
gap, since the position of the next strip is fixed by the relative motion of
the head and the tape.

Second, the drive has a 256kB buffer. That probably causes the 240kB record
size limit: The drive wants to have the WHOLE record in the buffer before
it starts writing. Why would anyone want to write records that large anyhow? 
Tape space usage is already maximized by having 8kB (or multiple) records.
The performance gain (CPU overhead for each record) should stop being 
significant long before you reach records that long, shouldn't it ?

-- 
Ralph Becker-Szendy                          UHHEPG=24742::RALPH (HEPNet,SPAN)
University of Hawaii                              RALPH@UHHEPG.PHYS.HAWAII.EDU
High Energy Physics Group                                  RALPH@UHHEPG.BITNET
Watanabe Hall #203, 2505 Correa Road, Honolulu, HI 96822         (808)956-2931