dump on old 1.2 Ultrix...

[George Robbins]

In article <413 at wuee1.wustl.edu> tjs at wuee1.wustl.edu (tom sullivan) writes:
> In article <7487 at cbmvax.UUCP> grr at cbmvax.UUCP (George Robbins) writes:
> >In article <1226 at gvgpsa.GVG.TEK.COM> davew at 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 at 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 at 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 at uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)