Xref: utzoo comp.periphs:3483 comp.sys.sgi:8351 comp.periphs.scsi:1927
Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!ubc-cs!uw-beaver!milton!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!uunet!infonode!ingr!b11!mcconnel
From: mcconnel@b11.ingr.com (Guy McConnell)
Newsgroups: comp.periphs,comp.sys.sgi,comp.periphs.scsi
Subject: Re: exabyte record size limit
Message-ID: <1991Feb14.223941.4318@b11.ingr.com>
Date: 14 Feb 91 22:39:41 GMT
References: <1991Feb8.152435.10875@helios.physics.utoronto.ca>
Reply-To: mcconnel@b11.UUCP (Guy McConnell)
Organization: Intergraph Corp. Huntsville, AL
Lines: 52

In article <1991Feb8.152435.10875@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?

    The maximum logical block size that the Exabyte supports is 240K.  Why?
I don't know.

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

   The Exabyte does not seperate physical records unless they are in different
save-sets.  At the end of a write operation the drive writes a "gap track" 
which consists of 8 "gap blocks", or one track (0.025mm wide) of non-data
that is not accessible by the user.  It uses this for orientation purposes on
an append operation.  If you tell it to, it then writes filemark(s) which *do*
take up a bit of space.  They are the equivalent of 2.2Mb long each.  This
sounds like a lot but during my capacity testing, I wrote 17 different data
save-sets to a 112m tape with a filemark between each and two filemarks at the
end.  I still got 2.3Gb of data on the tape.  Far more important is the use of
a blocking factor that is an even multiple of 8192.  Because of the way the
drive writes data on the tape, if you use something other than a product of
8K, you lose capacity.  Each helical track on the tape contains eight 1024 
byte *physical* blocks of user data.  The minimum writable unit for the drive
is one track.  Therefore, if you use a block size of, say, 10240, you'll get 
a logical block containing one track with 8K (8 1K blocks) of user data and
one track containing 2K of user data and 6K of "gap blocks".  Multiply this
by the length of a whole tape and it becomes significant.  Worse still, if 
you use a block size of 512 bytes, *each* physical block on the tape (1K each)
will contain 512 bytes of user data and 512 bytes of "pad data" which will
effectively cut the tape capaity in half.  I use a block size of 32768 and it
works fine.

--
==============================================================================
 Guy D. McConnell                   |            | "All that is gold does not
 Intergraph Corp. Huntsville, AL.   |  Opinions  | glitter, not all those who
 Mass Storage Peripheral Evaluation |   herein   | wander are lost, the old
 Tape Products                      |  are mine  | that is strong does not
 uunet!ingr!b11!mspe5!guy           |   alone.   | wither, and deep roots are
 (205)730-6289   FAX (205)730-6011  |            | not touched by the frost."
==============================================================================