arosen@hawk.ulowell.edu (MFHorn) (04/20/88)
Thanks.
This has probably come up before, but are there any ways to speed up [tar]
dumps of remote machines through NFS (besides 'get a faster machine/tape
drive')? More specifically, I log on to an 11/785 running Ultrix 2.0, and
type "tar c /nfs". /nfs is a remote partition mounted from a uVax II/GPX
(also running 2.0). It dumps with no problems to a tu81, but it takes 2
hours for one tape (neither machine had any users at the time).
Sometime this summer we should have NFS on a DG MV/10000 SX (which is why
we'll have to use tar and not dump) with just over 1G of disk and only a
1600 bpi drive (~30+ tapes for a full dump). We'll want to be able to dump
these disks to the tu81, but at 2 hrs/tape, it'll take almost an entire day.
[Not to mention the slew of disk/diskless workstations that might come in.]
I've tried playing around with the number of block I/O and mount daemons on
each machine; all combinations of each at 1 and 4. The times were all about
the same.
Is it the Ethernet that makes everything so slow or can we cut this time
down some? Is it the slow Ultrix tu81 driver or would 4.3 be faster?
One hour per tape would be great if we can get it.
Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I
ULowell, Box #3031 | ulowell!arosen | learned how to make it
Lowell, Ma 01854 | | talk" -Thunder Road
RD in '88 - The way it should bekai@uicsrd.csrd.uiuc.edu (04/23/88)
A few months ago a public domain TAR program was posted to one of the USENET
source newsgroups that allows manipulation of remote tape archives. It runs
a remote shell that executes DD to actually do the tape drive I/O, and pipes
the TAR output to it. I've found it to be pretty reliable. Maybe you can
try running this on the uVAX to see if that speeds up your dump.
I have only limited experiance with NFS, but what I saw was a three second
overhead for each file accessed, which might explain your slow dump.
If you are doing a full file system dump, why not use rdump instead?
Patrick Wolfe
Internet: pwolfe@kai.com
UUCP: ...!{uunet,ihnp4,ucbvax}!uiucuxc!kailand!pwolfe
The opinions expressed here are my own, NOT my employers.joe@tekbspa.UUCP (Joe Angelo) (04/23/88)
in article <6378@swan.ulowell.edu>, arosen@hawk.ulowell.edu (MFHorn) says: > > Thanks. > > This has probably come up before, but are there any ways to speed up [tar] > dumps of remote machines through NFS (besides 'get a faster machine/tape > drive')? More specifically, I log on to an 11/785 running Ultrix 2.0, and > type "tar c /nfs". /nfs is a remote partition mounted from a uVax II/GPX > (also running 2.0). It dumps with no problems to a tu81, but it takes 2 > hours for one tape (neither machine had any users at the time). Why not issue the tar command on the remote system via rsh and a dd conversion of block size? Oh, I forget the dd block size to use (see any of the sun application installation manuals) .. Try something like: rsh $remote -n '(cd / ; tar cbf YY - . | dd obs=XX ibs=XX)' > /dev/rmt8 NFS is gonna be slow no matter how you cut it simple because your local tar command will have to stat & read every remote file & directory OVER the network. The only things to check here are to make sure that your remote machine's tar command uses some default blocking factor (YY) and that the obs/ibs blocks used in dd (XX) match the blocking factor of your tape drive [and network?]. Of course, if your remote machine also swaps bytes, the "swab" option can be given to dd; depends on where you want to later read those tapes and how lazy you are. Can someone with more whit/stamina figure out the correct dd options? It's late and I'm tired :-{} [BTW: that was a yawn] Personally, I use multiple rdumps on the same tape for backups here and cpio for incrementals. -- "I'm trying Joe Angelo -- Senior Systems Engineer/Systems Manager to think at Teknekron Software Systems, Palo Alto 415-325-1025 but nothing happens!" uunet!tekbspa!joe -OR- tekbspa!joe@uunet.uu.net