Path: utzoo!attcan!uunet!snorkelwacker!apple!sun-barr!rutgers!cbmvax!grr
From: grr@cbmvax.commodore.com (George Robbins)
Newsgroups: comp.unix.ultrix
Subject: Re: _slow_ rdump
Message-ID: <15152@cbmvax.commodore.com>
Date: 15 Oct 90 11:19:28 GMT
References: <8844@pitt.UUCP> <1990Oct14.205942.27205@decuac.dec.com> <1990Oct15.034337.21119@watcgl.waterloo.edu>
Reply-To: grr@cbmvax.commodore.com (George Robbins)
Organization: Commodore, West Chester, PA
Lines: 30

In article <1990Oct15.034337.21119@watcgl.waterloo.edu> idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes:
> Here's stuff on dump/rdump I sent to comp.unix.ultrix last summer.
> We run Ultrix 3.1 and 3.1C.
... ... ... ...
> 
> I think the problem is just that dump uses too many buffers and in Ultrix
> 3.1C that makes things worse rather than better.  Or perhaps dump's
> buffers aren't aligned on page boundaries, and dd's are.  (See Ultrix
> Version 3.1C Release Notes section 1.1.12.)

Somewhere in the Ultrix 4.0 Release notes, it admits that multi-buffer I/O
sucks if the buffers aren't "properly aligned".  This might explain why
dump gets slow, but leaves it as an open question why they didn't bother
to fix the underlying problems in dump or multi-buffer I/O...

Perhaps using Ultrix 1.2 dump is the ticket?  Before they kludged in the
multi-buffered I/O and the generic syscalls?  Where did I put that release
tape...   8-)  BTW, dump really seems to work just fine on my configuration,
5810/HSC50/TA78, but I don't have much to compare it with.

BTW, I'd still like to get the patches to BSD 4.3 dump to sleaze over
the differences between the 4.3 include files and what resolves out of
the ultrix [gvi]node equates.  Somebody last year claimed that this was
"easy", but perhaps this was a theoretical assertion?


-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)