TAR DOES NOT SWAP BYTES (3B20 tape block size)
Darryl Baker
dpb at laidbak.UUCP
Wed Oct 16 13:51:43 AEST 1985
In article <1473 at gatech.CSNET> arnold at gatech.CSNET (Arnold Robbins) writes:
>In article <578 at im4u.UUCP>, jsq at im4u.UUCP (John Quarterman) writes:
>> >I think the problem is with the 3B20 tape drive, not with "tar" on the 3B20.
My old job was in AT&T UN*X Support and the brain damage is in
the un52 tape controller.
......
>The actual limit for blocks that can be written to and read from the tape
>drive on the 3B20 is 6K (using the raw device).
......
>This limit really sucks. Whoever made that decision at AT&T must not have
>been someone who actually had to move tapes around. When is AT&T going
>to take their heads out of the sand? The 3B20s are hardware to run UNIX
>on, not the other way around!!!
>--
Yes, they really have problems with tapes. The first 3B20s had
tape drives that could only handle 2K blocks. The second cut at
tape drives had the 6K limit. The third cut (latest as of my
leaving AT&T) did handle 10K at least but took a special IOP
to handle it. This was because of the I/O bandwith of the
dual serial channel. Too much other traffic and the streamer
tape drive couldn't stream and was slower than the non-streamer.
If they wanted the 3B20 to run well they would chuck the dual
serial channel.
--
from the sleepy terminal of
Darryl Baker
[ihnp4!]laidbak!dpb
More information about the Comp.unix.wizards
mailing list