TU-78 tape drives and EOT

[chris at mimsy.UUCP]

In article <646 at cygnet.CYGNETSYSTEMS> will at cygnet.CYGNETSYSTEMS
(Will Nelson) writes:
>... when we dump a filesystem large enough to require more than one
>tape[, w]hen EOT is reached, dump returns a tape write error rather
>than a message to mount another tape.

Most likely you have a short tape.

>The zinger is that when we use rdump to dump the same filesystem
>to the same tape, when the tape is mounted on another tape drive
>on another system, the darn thing works as expected!:

Different tape drives have different inter-record gaps (IRGs), and
therefore manage to use a bit more or less of the available space.
This is probably just luck.

>... The tentative conclusion we've reached here is that the TU-78
>tape driver is less efficient in its use of tape, and that the
>calculations of how much filesystem (mounted read-only) will fit
>on how many tapes are somewhat off at 6250 for the TU-78.

4.2BSD's dump calculations *are* off, but in the other direction:
it uses too little of each tape.  This has been fixed in many
4.2BSD variants.

>I say this primarily from watching the tape movements while dumping 
>and rdumping. The Cypher on the remote machine is constantly "shoe-shining",
>ie, goes forward a bit, rewinds a bit less, back and forth at 6250, whereas
>the TU-78 never rewinds.

The one that goes forward and back is a `streaming' drive, so called
because the tape never streams :-) .  (Actually, if you push data
at it fast enough, most streamers will stream.  The problem is the
`fast enough'.  One streaming drive on an old Pyramid of ours has
such a slow controller that even the seek operations do not stream!)
The TU78 is a `start-stop' drive, and does not need to build up
forward momentum before writing to the tape.

A streaming 6250 tape drive that runs at 100 ips must be fed at
about 625000 bytes per second in order for it to run continuously.
(Ignoring IRGs and such makes the calculations easy.  It is really
more in the range 500 to 600 K/s, depending on block size and IRG.)
This is faster than some buses or disk drives.  Some controllers
provide a cache that (in theory) helps keep the tape streaming.
Note, however, that a 600 Kbyte cache can only run the tape for
one second.  The little 128K caches found in some controllers are
virtually useless at this rate.  Now, if the tape drive had a 6
*mega*byte cache. . . .
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris at mimsy.umd.edu