will@cygnet.UUCP (02/06/87)
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
chris@mimsy.UUCP (02/07/87)
In article <646@cygnet.CYGNETSYSTEMS> will@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@mimsy.umd.edu
mangler@cit-vax.UUCP (02/16/87)
In article <646@cygnet.CYGNETSYSTEMS>, will@cygnet.CYGNETSYSTEMS (Will Nelson) writes: > 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. Cipher streamers are strict about adhering to the gap-length standards, they always write exactly the minimum gap, unlike other streamers which write gaps up to twice as large if they need to in order to keep streaming. This makes Cipher's very hard to stream without a cache. That's why cache is standard on most Cipher models. Some start/stop GCR drives write 0.6 inch gaps. The TU-78 is similar to the TU-77, a drive that writes 0.6 inch gaps; perhaps the TU-78 falls in this class? Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speck