TU-78 tape drives and EOT

[will at cygnet.UUCP]

I have a problem using dump on a VAX 785 running 4.2BSD with NFS.
The tape drive is a TU-78 9-track tape drive. The problem occurs
when we dump a filesystem large enough to require more than one
tape. When EOT is reached, dump returns a tape write error rather
than a message to mount another tape. The actual syntax is:

	dump 0df 6250 /dev/rmt8 /dev/rra1g

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!:

	rdump 0df 6250 cygnet:/dev/rmt8 /dev/rra1g

The phenomenon appears to be selective to the high density; things
work OK at 1600 bpi. The fact that the rdump works rules out any
involvement of NFS. 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.
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.

My question is, has anyone else out there experienced a similar situation?
We have a workaround by specifying -s 2200 on the dump command line,
but I'm curious as to whether my tentative conclusion has some basis
in fact, or do we have some other hardware problem that the CDC repairmen
can't fix?


-- 
Will Nelson		uucp: ucbvax!decvax!decwrl!pyramid!oliveb!cygnet!will
Cygnet Systems, Inc.
601 West California Avenue
Sunnyvale, CA  94086-4831
(408) 773-0770