Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ucsfcca.UUCP Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!ucsfcgl!ucsfcca!goldman From: goldman@ucsfcca.UUCP (Eric Goldman) Newsgroups: net.unix-wizards Subject: Re: Ultrix dump to TK50 not using entire tape? Message-ID: <471@ucsfcca.UUCP> Date: Thu, 27-Mar-86 21:00:43 EST Article-I.D.: ucsfcca.471 Posted: Thu Mar 27 21:00:43 1986 Date-Received: Tue, 1-Apr-86 05:08:16 EST References: <257@cirl.UUCP> Reply-To: goldman@ucsfcca.UUCP (Eric Goldman) Distribution: net Organization: UCSF Computer Center Lines: 76 [] In article <257@cirl.UUCP> das@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 #include static long fssize; static int mt = -1; static int pipein = 0; --- 12,20 ----- #include #include + #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@ucsf-cgl.ARPA UUCP: ucbvax!ucsfcgl!cope.ucsf!goldman