bbraden@mesrx.UUCP (Bill Braden) (11/21/90)
Making the jump from VMS system managment to ULTRIX system managment sure is fun. Here is a little problem that some of you expirenced super users might be able to help with. I am doing a level 0 dump of my file systems to TK-70. The file system in question is under 200mb. A TK-70 is supposed to hold 295mb. Why does dump require 3 tapes? ------------------------------- #df Filesystem Total kbytes kbytes % node kbytes used free used Mounted on /dev/ra1a 7407 5324 1343 80% / /dev/ra0c 145726 111987 19167 85% /usr /dev/ra1g 41639 6069 31407 16% /var /dev/ra7h 316335 155075 129626 54% /usr/news /dev/ra4f 197627 165024 12841 93% /awb # dump 0 /dev/ra4f DUMP: Date of this level 0 dump: Tue Nov 20 15:21:20 1990 DUMP: Date of last level 0 dump: Thu Nov 15 07:55:37 1990 DUMP: Dumping /dev/rra4f (/awb) to /dev/rmt0h DUMP: Mapping (Pass I) [regular files] DUMP: Mapping (Pass II) [directories] DUMP: Mapping (Pass II) [directories] DUMP: Mapping (Pass II) [directories] DUMP: Estimates based on 1200 feet of tape at a density of 10240 BPI... DUMP: This dump will occupy 17987 (10240 byte) blocks on 2.12 tape(s). -------------------------------- Have I got something setup strange, does the system think its a TK-50? Should I be using B,d or s options? Is dump just a tape hog? Or should I just stick to VMS? --Bill Braden (Measurex Inc.) Onward Through the Fog!
rauletta@gmuvax2.gmu.edu (R. J. Auletta) (11/24/90)
In article <517@mesrx.UUCP> bbraden@mesrx.UUCP (Bill Braden) writes: >I am doing a level 0 dump of my file systems to TK-70. The file system >in question is under 200mb. A TK-70 is supposed to hold 295mb. Why >does dump require 3 tapes? Use the s option with 4800 as the argument..like dump 0usf 4800 /dev/nrmt0h filesystem1 dump 0usf 4800 /dev/nrmt0h filesystem2 dump 0usf 4800 /dev/nrmt0h filesystem3 to dump several partitions to a single tape. (If you wish to dump one filesystem then use *dump 0us 4800*, but using 290Meg to hold hold a small partition seems wasteful.) This works quite well for incremental dumps as the whole file system can most likely be dumped without *changing* tapes. Beware though, accessing the last dump file on a multi-dump tape can *take a while*. (Using either *mf fsf #* or *restore s #*. Interestingly under Ultrix 2.0 dump would use EOT to sense the end of the tape and still dump correctly even without the s option. Not so under 3.0 and 3.1. -R J Auletta rauletta@sitevax.gmu.edu
alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.) (11/25/90)
In article <517@mesrx.UUCP>, bbraden@mesrx.UUCP (Bill Braden) writes: > Making the jump from VMS system managment to ULTRIX system managment > sure is fun. Here is a little problem that some of you expirenced > super users might be able to help with. > > I am doing a level 0 dump of my file systems to TK-70. The file system > in question is under 200mb. A TK-70 is supposed to hold 295mb. Why > does dump require 3 tapes? > > [ Example dump deleted. ] What version of ULTRIX are you running? Before V4.0 dump(8) calculated how much tape a particular backup based on the length of tape, density, inter-record gap, phase of moon, etc. For nice normal 9 track tape drives this always worked well. For nearly anything else the algorithm breaks and you sometimes have to hand dump(8) slightly bogus numbers to get it estimate correctly. Previously these estimates were used to decide when to go to the next tape of a volume. I think in V4.0 it just keeps dumping until it hits EOT, then goes to the next tape. > > Have I got something setup strange, does the system think its a TK-50? > Should I be using B,d or s options? Is dump just a tape hog? Or should > I just stick to VMS? I think more recent versions of dump(8) will say what kind of tape they think they are talking to. I didn't look closely enough at your listing to see. If you're running V4.0 then there shouldn't be a problem. Otherwise check the release notes to see if says what the incantation is for a TK70 on your particular version. > > --Bill Braden (Measurex Inc.) > > Onward Through the Fog! -- Alan Rollow alan@nabeth.enet.dec.com