Ultrix dump to TK50 not using entire tape?

[Eric Goldman]

[]
In article <257 at cirl.UUCP> das at cirl.UUCP (Dave Steffens) writes:
>We are running Ultrix version 1.1 on a uVAX II with TK50 cartridge tape drive.
>When dumping our main filesystem to TK50 tape, we noticed that each cartridge
>appears to hold only about 40Mb instead of its rated capacity of 95Mb.
>What's going on here?
>
>P.S. The TK50 is **very** slow -- it takes almost 3 hours to put 40Mb of dump
>on the TK50 whereas it takes only about 45 minutes to put 40Mb of dump
>on our ancient PDP11/34 magtape (Digidata 800bpi 45ips).
>-- 
>{harvard,mit-eddie,think}!eplunix!earvax!das	David Allan Steffens
>243 Charles St., Boston, MA 02114		Eaton-Peabody Laboratory
>(617) 523-7900 x2748				Mass. Eye & Ear Infirmary

Your problem is that your are dumping tapes using the default blocking factor
(10) , and the default tape size (2300).  An undocumented "feature" of dump is
that you can specify another blocking factor.  We have a uVAX II running
Ultrix 1.1, and we dump and restore using the maximum blocking factor, 126,
and a "large" tape length of 4800.  We have crammed > 80 MB onto a TK50, as
follows:

	dump 0ubs 126 4800 /usr

There is one major "gotcha," however:  restore, as provided in standard 4.2bsd
and Ultrix, does not know how to read these 126-blocking-factor tapes!  It has
a blocking factor of 10 hardwired into the code.  Sun has fixed this in their
distribution, but we VAX users have to modify the restore source and create a
version of restore which can work with these tapes.  I took the quick-and-
dirty approach and created restore126, which has two lines added to the file,
tape.c, (renamed tape126.c), as follows:

*** tape.c      Wed Oct 16 10:38:24 1985
--- tape126.c   Wed Oct 16 10:38:24 1985
***************
*** 12,17
  #include <setjmp.h>
  #include <sys/stat.h>

  static long   fssize;
  static int    mt = -1;
  static int    pipein = 0;

--- 12,20 -----
  #include <setjmp.h>
  #include <sys/stat.h>

+ #undef NTREC
+ #define NTREC 126
+
  static long   fssize;
  static int    mt = -1;
  static int    pipein = 0;

As you can see, I simply changed the hardwired blocking factor, NTREC, from 10
(as defined in the include file, /usr/include/dumprestor.h) to 126.  A more
elegant solution would read the command line for the b flag, as does dump, and
allocate memory appropriately for the blocking factor.  Since my quick fix has
worked perfectly for several months now (dumps go > 3 times faster, and
restores have been quick and error-free), I have not been inclined to do a
nicer fix.

If you do not have source, I will mail you a uuencoded version of the
restore126 binary.  Dump, as mentioned, needs no modification, since the b flag
is there, albeit undocumented.

BTW, you should also use the 126 blocking factor for tar, and you'll really
see the TK50 stream:

	tar cb 126 whatever
	tar xpb 126 whatever

--Eric S. Goldman, M.D.
  UCSF School of Medicine
  ARPA: cope.ucsf!goldman at ucsf-cgl.ARPA
  UUCP: ucbvax!ucsfcgl!cope.ucsf!goldman