exabyte record size limit

[Dave Olson]

In <1991Feb8.152435.10875 at helios.physics.utoronto.ca> sysmark at 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!

It was available all along; you just needed to run cd /dev; MAKEDEV tps to
create them...

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

240K is the amount of usable RAM on the drive for buffering data, and 
this limits the maximum size of a single 'block', due to the way
the drive firmware is written.  The actual blocking on the tape is 1K
in any case, so you gain little or nothing in performance by increasing the
size past about 128K.

| 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 only thing you gains is if it makes your software easier to write.
The 'block size' is written as part of the header info.  Larger block
sizes gain you no capacity or performance.  You DO want to make sure the
block sizes is a multiple of 1024 for maximum capacity, otherwise the
size % 1024 is wasted in the last 'real' block of each write; a block
size of 512 wastes half the tape.