kevin@kosman.UUCP (Kevin O'Gorman) (05/28/87)
Running dump(8) on a MicroVAX, Ultrix 1.2A -- and I'm getting REAL tired
of waiting for the tape. The tape unit is a streamer, and the software
is not fast enough to keep it in streaming mode, so I wait and wait and
wait....
Is there any software anything like dump/restore that keeps up with a
streamer, or some way to speed up (double-buffer) dump/restore enough to
do so?
--
Kevin O'Gorman
...{decvax,allegra}!philabs!hhb!kosman!kevinpdb@sei.cmu.edu (Patrick Barron) (05/30/87)
In article <241@kosman.UUCP> kevin@kosman.UUCP (Kevin O'Gorman) writes: >Is there any software anything like dump/restore that keeps up with a >streamer, or some way to speed up (double-buffer) dump/restore enough to >do so? The problem isn't with dump/restore, the problem's in the tmscp driver. They've reworked the driver in Ultrix 2.0. At the recent DECUS symposium in Nashville, DEC said that TK-50 throughput in 2.0 is increased by a factor of 12! Your best bet is probably to get 2.0. --Pat.
karl@grebyn.COM (Karl A. Nyberg) (05/31/87)
In article <241@kosman.UUCP>, kevin@kosman.UUCP (Kevin O'Gorman) writes: > Running dump(8) on a MicroVAX, Ultrix 1.2A -- and I'm getting REAL tired > of waiting for the tape. The tape unit is a streamer, and the software > is not fast enough to keep it in streaming mode, so I wait and wait and > wait.... > > Is there any software anything like dump/restore that keeps up with a > streamer, or some way to speed up (double-buffer) dump/restore enough to > do so? I know that's probably mindless, but apparently some significant speedup has been made in this area in 2.0. You can also run the dump at night, and go to bed... Now, the next question is when the 2.0 that was scheduled for release 1 April is going to be delivered... -- Karl DDN: nyberg@ada20.isi.edu INET: karl@grebyn.com - AKA - karl%grebyn.com@seismo.css.gov uucp: {decuac, seismo}!grebyn!karl
mouse@mcgill-vision.UUCP (06/07/87)
In article <241@kosman.UUCP>, kevin@kosman.UUCP (Kevin O'Gorman) writes: > Running dump(8) on a MicroVAX, Ultrix 1.2A -- and I'm getting REAL > tired of waiting for the tape. The tape unit is a streamer, and the > software is not fast enough to keep it in streaming mode, so I wait > and wait and wait.... Dump and restore through dd, that seems to help. Try something like # dump 0uf - /dev/rra2g | dd obs=1024x1024 conv=block > /dev/rmt12 or # dd ibs=1024x1024 if=/dev/rmt12 conv=unblock | restore rf - (of course, change /dev/... and dump/restore options to suit). der Mouse (mouse@mcgill-vision.uucp)
robin@itcatl.UUCP (Robin Cutshaw) (06/13/87)
In article <241@kosman.UUCP>, kevin@kosman.UUCP (Kevin O'Gorman) writes: > Running dump(8) on a MicroVAX, Ultrix 1.2A -- and I'm getting REAL > tired of waiting for the tape. The tape unit is a streamer, and the > software is not fast enough to keep it in streaming mode, so I wait > and wait and wait.... > Use b and s flags (bs 126 7400) and it will stream. Restore will also work under Ultrix using the b flag (b 126) flag. Our backup script follows... #!/bin/csh if ($#argv != 1) then echo "Usage: quickdump level" exit endif echo -n "Dump starting at " >&/usr/adm/lastdump.$1 /bin/date >>&/usr/adm/lastdump.$1 /etc/dump $1ucbsf 126 7400 /dev/nrmt8 / >>&/usr/adm/lastdump.$1 echo "" >>&/usr/adm/lastdump.$1 /etc/dump $1ucbsf 126 7400 /dev/nrmt8 /usr >>&/usr/adm/lastdump.$1 echo "" >>&/usr/adm/lastdump.$1 /etc/dump $1ucbsf 126 7400 /dev/nrmt8 /u >>&/usr/adm/lastdump.$1 echo "" >>&/usr/adm/lastdump.$1 /etc/dump $1ucbsf 126 7400 /dev/nrmt8 /usr/ita >>&/usr/adm/lastdump.$1 echo "" >>&/usr/adm/lastdump.$1 if (X$1 == "X0") then mt -f /dev/rmt8 rew echo "Change tapes for level 0 dump. Hit <CR> to continue." >>&/usr/adm/lastdump.$1 $< endif /etc/dump $1ucbsf 126 7400 /dev/rmt8 /u/usr >>&/usr/adm/lastdump.$1 echo "" >>&/usr/adm/lastdump.$1 echo -n "Dump finished at " >>&/usr/adm/lastdump.$1 /bin/date >>&/usr/adm/lastdump.$1 And here is the restore script (note that we place several partitions on one tape)... #!/bin/csh if ($#argv != 1) then echo "Usage: quickrestore [0-4]" exit endif mt -f /dev/rmt8 rew echo -n "Restore starting at " /bin/date if (X$1 != "X0") mt -f /dev/nrmt8 fsf $1 /etc/restore ibf 126 /dev/nrmt8 echo -n "Restore finished at " /bin/date We use restore by itself for the last partition restoration. robin
jerry@oliveb.UUCP (06/15/87)
In article <241@kosman.UUCP> kevin@kosman.UUCP (Kevin O'Gorman) writes: >Running dump(8) on a MicroVAX, Ultrix 1.2A -- and I'm getting REAL tired >of waiting for the tape. The tape unit is a streamer, and the software >is not fast enough to keep it in streaming mode, so I wait and wait and Modifications to dump were distributed on the net. They are also in the 4.3BSD dump. The basic change is for dump to fork several copies of itself. This creates a "ring" of dumps that write to the tape as soon as the previous process finishes. The effect is to provide double (actually multiple) buffering. I tried the changes here and the improvement on a regular tape drive was about twice as fast. A friend at sci tried it out on a MicroVAX-TK-50 combination and said the improvement was about 5-8 times. This is because the streaming comes into effect. If you have the source to your dump routine then I could send you the patches. Otherwise DEC will presumably include this, along with other 4.3BSD changes, in a future realease. Someone should really bug them to make the dump inhancements immediately available, expecially to TK-50 users. A side effect of the dump speedup is a greater load on the system. Depending on the speed of the CPU vs the tape, dump can create a load of 3 or more by itself. This is, of course, not a factor if the system is single user.
mohamed@hscfvax.UUCP (750025@Mohamed_el_Lozy) (06/22/87)
In article <237@itcatl.UUCP>, robin@itcatl.UUCP (Robin Cutshaw) writes: > In article <241@kosman.UUCP>, kevin@kosman.UUCP (Kevin O'Gorman) writes: > > Running dump(8) on a MicroVAX, Ultrix 1.2A -- and I'm getting REAL > > tired of waiting for the tape. > > Use b and s flags (bs 126 7400) and it will stream. Restore will also > work under Ultrix using the b flag (b 126) flag. Our backup script follows... Under our 1.2 Ultrix system, restore(8) does not rcognize the 'b' key. Since we have all source licenses, we compiled the 4.3 dump/restore pair and did some timings. On a single user MicroVAX we got about a threefold speedup, MOST impressive. On an 8200 with TU-81 tape drive we got the following timings on /dev/rra0g, which has about 30 Meg on it, dumping at 6250 bpi: standard dump (no 'b' key) 15:53 clock time Ultrix 1.2 dump, b 256 12:10 clock time BSD 4.3 dump, b 256 8:10 clock time These speedups are most welcome when dumping several ra81's.