kai@uicsrd.csrd.uiuc.edu (Kuck And Associates) (06/13/90)
Thanks to all who responded to my plea for help getting wbak to work to an Exabyte tape drive on a remote Unix host. My backup script contains: wbak -stdout //quantum | rsh illiant dd ibs=8k obs=32k of=/dev/nrcartridge which works fine. The key to the solution was using 8k input blocks (I had 4k originally). The only problem left is how slow this is. I can juggle our backup schedule around so the dn10000 is dumped overnight, but it seems a little strange that such a blazing fast system (and I do mean FAST!) should have such a slow, plodding backup utility. It takes over 4 hours to dump a single 700 Mb disk, more time than it takes to dump the entire 2 Gb from our Sequent S81 (to the same drive). Patrick Wolfe (pat@kai.com, kailand!pat) System Programmer/Operations Manager, Kuck & Associates
awhitton@bcara132.bnr.ca (Alan Whitton) (06/13/90)
In article <1990Jun13.012834.1159@csrd.uiuc.edu>, kai@uicsrd.csrd.uiuc.edu (Kuck And Associates) writes: > The only problem left is how slow this is. I can juggle our backup schedule > around so the dn10000 is dumped overnight, but it seems a little strange that > such a blazing fast system (and I do mean FAST!) should have such a slow, > plodding backup utility. It takes over 4 hours to dump a single 700 Mb disk, > more time than it takes to dump the entire 2 Gb from our Sequent S81 (to the > same drive). > > Patrick Wolfe (pat@kai.com, kailand!pat) > System Programmer/Operations Manager, Kuck & Associates Ah but to paraphrase our friends at SUN: The Network IS the problem No matter how fast your system is, if your network is a standard ethernet (or normal token ring for that matter), the bottle neck will be the network and not your system. Also are the DN10000's disks fast? I don't think they are compared to some of the new technologies coming out. Are their any plans out their in HP land to speed up the disks on the 10000? Cheers, Alan -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- BNR Ottawa Disclaimer: "This is only my opinion" BITNET: awhitton@bnr.ca OR UUCP: ...uunet!bnrgate!forum!awhitton
krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (06/13/90)
Apollo's file system / backup facility allows for roughly 150 to 200 MB per hour to be accessed. We have found that running wbak on a DN3500 with a 690 MB Maxtor drive (the fastest drive Apollo sells) with large (>100 block) files being dumped to /dev/null (ie. being tossed into the bit bucket so it wasn't taking up any time waiting for the tape drive) gives us about 200 to 250 MB per hour. The bottle neck appears to be the time needed to access all the control info (protection, extended ACLS, object type, etc.) for the file system. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
achille@cernvax.UUCP (achille petrilli) (06/15/90)
In article <1990Jun13.115943.4352@bnrgate.bnr.ca> awhitton@bnr.ca writes: >In article <1990Jun13.012834.1159@csrd.uiuc.edu>, >kai@uicsrd.csrd.uiuc.edu (Kuck And Associates) writes: >> The only problem left is how slow this is. I can juggle our backup schedule >> >> Patrick Wolfe (pat@kai.com, kailand!pat) >> System Programmer/Operations Manager, Kuck & Associates > >Ah but to paraphrase our friends at SUN: > > The Network IS the problem > >No matter how fast your system is, if your network is a standard ethernet >(or normal token ring for that matter), the bottle neck will be the network >and not your system. > >Also are the DN10000's disks fast? I don't think they are compared to some >of the new technologies coming out. Are their any plans out their in HP >land to speed up the disks on the 10000? > >Cheers, >Alan > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >BNR Ottawa Disclaimer: "This is only my opinion" >BITNET: awhitton@bnr.ca OR UUCP: ...uunet!bnrgate!forum!awhitton I just ran 'time wbak -stdout -full -nhi /systest >/dev/null' and it took 9.58sec for 9.736MB of real time == 1MB/sec The problem for you is using the rsh command. Use directly the 'shell' service and write your own remote execution WITHOUT invoking the intermediate /bin/sh. Also some Unixes (i.e. Unicos/Cray) allow you to set the buffer size for net transfers, set it to some 64KB. I'm sorry I forgot the name of the ioctl I used :-) It was long ago. Achille Petrilli Management Information Systems