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