Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!cbmvax!grr From: grr@cbmvax.UUCP (George Robbins) Newsgroups: comp.unix.ultrix Subject: Re: dump on old 1.2 Ultrix... Message-ID: <7502@cbmvax.UUCP> Date: 1 Aug 89 23:26:08 GMT References: <412@wuee1.wustl.edu> <1226@gvgpsa.GVG.TEK.COM> <7487@cbmvax.UUCP> <413@wuee1.wustl.edu> Reply-To: grr@cbmvax.UUCP (George Robbins) Organization: Commodore Technology, West Chester, PA Lines: 86 In article <413@wuee1.wustl.edu> tjs@wuee1.wustl.edu (tom sullivan) writes: > In article <7487@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > >In article <1226@gvgpsa.GVG.TEK.COM> davew@gvgpsa.gvg.tek.com (David C. White) writes: > > >> It may be possible to grab the driver out of the 3.0 you seem to > >> imply that you have, but I haven't really looked into whether > > This is all due to my original posting. I have tried the 3.0 dump, and > George Robbins is correct, the drivers don't work. I have tried a 4.3 > dump and it appears to be working well. Dump times for 80 Meg are > down from 6+ hours to about 30 minutes. Hey, I'm glad it worked out! Now if I could get that kind of improvment out of restore doing a 500 M-byte restore on a new spool, I'd be one happy puppy. Hopefully all the net fuss has also clarified a few other issues an others can benefit from tuning their backup prodcedures. > >Drivers are generally not binary transportable across major releases and the > >3.0 stuff especially, since kernel level memory allocation stuff changed. There are actually several issues here. I think davew@gvgpsa.gvg.tek.com (David C. White) wanted you to steel the kernel level drivers from 3.0 and use them to build your 1.2 kernel. This isn't going to work, for the reasons I mentioned. The other problem is that there is no real guarantee of backwards binary compatibility between Ultrix X.Y and either earlier Ultrix/BSD releases nor between post 4.2 BSD executables and Ultrix. As part (probably) of the nbuf stuff, dump executes a new "generic" system call to find out device characteristics. It looks like if this fails, it's supposed to act stupid and work anyway, but actually it just hangs. This system call doesn't exist in older release of Ultrix and then system call number (and data format?) changed between 2.x and 3.x making those verions of dump binary incompatible, though the tapes can certainly be interchanged. The rdump protcol has also changed thru different releases, which can cause some headaches in a mixed relase Ultrix and/or mixed Ultrix Sun environment. The 3.x rdump seems to talk to everybody else at least. 4.3 Tahoe binaries also diverge from Ultrix, apparently in the general area of signal handling. Simple stuff will run, but more sophisticated programs will blow off. Some Ultrix 3.0 binaries also get pretty spooky if you try to run them on either plain 4.3 or 4.3 Tahoe. Play these games at your own risk. I'd like to thank alan@shodha.dec.com for explaining the implications out of the nbuf features. A while back I was really puzzled as to why the vaunted 4.3 BSD dump wasn't as much faster as it was reputed to be. It's appears that by adding the nbuf stuff DEC was able to get as much of an asynchronous I/O effect/improvment as the Berkeley multiple-process 4.3 kludges. The rational end-of-tape fixes to dump/tar/dd are also very nice. I had noticed this with dump but kind of forgotten it, since I use the 4.3 dump for all my level 0 / multi-volume dumps. It is a nice win to not have to specify -s 3450 for a 3600 foot reel of tape and then watch the silly thing want to put a couple hundred blocks on a thrid reel. Maybe we can summarize and put this one to bed: a) There is nothing particularly wrong with the Ultrix 2.x / 3.x dump program (unless you're running 1.2). It is as fast/efficient as the current BSD dump program and has the -b switch to allow mucking with block sizes though it's undocumented and may be unecessary. It has some improvments in the area of end-of-tape handling. b) The Ultrix restore program works ok, though it doesn't support the -b switch. Restore times tend to be more dependent on file creation speed than tape speed, so I don't see any real performance issue here, though someone with a streamer drive might. I did run into some heavy duty problems when trying to restore a large news spool not too long ago. Since the news spool is overly endowed with links, the restore had sucked up something over 8-MB of memory and was getting into some paging. It tooks the system out a couple of time by corrupting the swap space and I eventually had to run it single user. In retrospect I think it was a problem with having swapon re-add the root area (which is used to detect and refuse to do) leading to a corrupted swap map, but I never did get back to analyzing the problem. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)