Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: mangler@csvax.caltech.edu (Don Speck)
Newsgroups: comp.sys.sun
Subject: Re: What is the 'real' tape length
Message-ID: <8901230849.AA20878@csvax.caltech.edu>
Date: 31 Jan 89 17:04:13 GMT
Sender: usenet@rice.edu
Organization: California Institute of Technology
Lines: 63
Approved: Sun-Spots@rice.edu
Original-Date: Mon, 23 Jan 89 00:49:35 PST
X-Sun-Spots-Digest: Volume 7, Issue 129, message 9 of 10

Half-inch magtape has a usable length about 40 to 60 feet shorter than the
stated length, due to the leader and trailer.	Minimum interrecord gaps
are 0.3 inches for 6250 Bpi, and 0.6 inches for 800, 1600, or 3200 Bpi.
Streamers with a 1600-Bpi 25-ips start/stop mode need 0.8 inches.  In all
other cases, streamers have to reposition if the next block is not
supplied soon enough, and since this is so slow, some streamers stretch
out the minimum interrecord gap by 50% (CDC 92181 or 92185) or even 100%
(DEC TU80) in hopes of avoiding this, which is how a Sun-3/160 or VAX-750
respectively is able to stream them at all.  When they reposition, the
interrecord gap is maximum length.  Cache streamers write minimum
interrecord gaps, at the price of making the return value of write()
essentially meaningless.

Quarter-inch cartridges appear to have no leader or trailer, a minimum
interrecord gap of about 0.2 inches, a maximum interrecord gap of 1.6
inches, and when they reposition they leave a minimum interrecord gap,
which is probably why this action takes about 1.6 seconds.

Early Sun quarter-inch cartridge streamers had no cache.  A Sun-3/160
isn't fast enough to stream one unless the blocksize is 2 KB or less,
which results in interrecord gaps averaging about 1.1 inches.  In typical
use, they reposition after every block, with minimum interrecord gaps.

Later drives have a small cache, and will stream if the blocksize is not
too big for the cache.  I'm not sure what this cutoff is, but it seems to
be somewhere between 10K and 63K (I've had little access to such drives).
These drives seem to always write minimum interrecord gaps, so there is no
real capacity gain from using huge blocksizes.

Interrecord gap is the one tape parameter that can't be specified to dump.
The values used by various versions are:

				'c' option  dens=6250	dens=other
	4.1 BSD 		    -	       0.7	    0.7
    *	4.2, 4.3, 4.3T estimates   1.548       0.3	    0.7
	4.2 BSD actual		   0.7	       0.7	    0.7
	4.3 beta actual 	   1.6	       0.4	    0.8
	4.3, 4.3T BSD actual	   1.6	       0.5	    0.8
	SunOS 1.1 to 3.5	   1.6	       0.6	    1.2
(* yes, the tape usage estimate uses a separate value of interrecord
gap, which Berkeley hasn't changed to match the rest of BSD dump).

In principle, the above information should be enough to calculate the
"right" parameters to dump.  Dump will compute how many tenths of an inch
per block written, truncating to an integer (a problem for high densities)
and use that to add up the length written.

If dump's hardcoded interrecord gap is wrong (usually), you can lie to
dump about the tape length, but this lie will differ depending on the
blocksize.  The only way to make one length work for all blocksizes is to
lie about the density, too, dividing it by the ratio of actual interrecord
gap to dump's value (and multiplying the length by the same factor).  For
example, extracting some figures from George Goble's excellent article on
Exabytes:

			     actual	 scaling   fiction for dump
	interrecord gap     0.015 inch	  * 80	 =    1.2 inch
	density 	    550700 Bpi	  / 80	 =    6884 Bpi
	length		    348 feet	  * 80	 =    27840 feet

Using this fiction, SunOS 3.5 dump will calculate a capacity of 1812 MB
for blocksize=32K, and 2004 MB for blocksize=63K.  (N.B. I do not have an
Exabyte to try this on, nor a 2000 MB filesystem).