Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site gatech.CSNET
Path: utzoo!linus!gatech!arnold
From: arnold@gatech.CSNET (Arnold Robbins)
Newsgroups: net.unix-wizards
Subject: Re: TAR DOES NOT SWAP BYTES (3B20 tape block size)
Message-ID: <1473@gatech.CSNET>
Date: Fri, 11-Oct-85 13:03:21 EDT
Article-I.D.: gatech.1473
Posted: Fri Oct 11 13:03:21 1985
Date-Received: Sat, 12-Oct-85 05:27:58 EDT
References: <235@thunder.UUCP> <604@neuro1.UUCP> <2818@sun.uucp> <471@mtxinu.UUCP> <578@im4u.UUCP>
Organization: Pr1mebusters!
Lines: 27
Summary: Actual measured 3B20 tape block size

In article <578@im4u.UUCP>, jsq@im4u.UUCP (John Quarterman) writes:
> >I think the problem is with the 3B20 tape drive, not with "tar" on the 3B20.
> >Some tape controller (which I think they've junked in favor of a sane one)
> >imposes a rather small minimum block size; "tar cb 20 ..." exceeds this
> >limit.
> 
> The limit is 10, and you also have to specify the blocksize manually
> when extracting a tape, as well as when writing one.
> -- 
> John Quarterman

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).  I found this out when porting
a really neat backup program to our two 3B20s. So Jsq's comment is correct,
a tar block size of 10 is 5K bytes (tar's "block" is 512 bytes).

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!!!
-- 
Arnold Robbins
CSNET:	arnold@gatech	ARPA:	arnold%gatech.csnet@csnet-relay.arpa
UUCP:	{ akgua, allegra, hplabs, ihnp4, seismo, ut-sally }!gatech!arnold

Hello. You have reached the Coalition to Eliminate Answering Machines.
Unfortunately, no one can come to the phone right now....