Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: rdump, Ethernet slowness
Message-ID: <57900004@ccvaxa>
Date: 11 Dec 87 05:17:00 GMT
References: <788@hsi.UUCP>
Lines: 33
Nf-ID: #R:hsi.UUCP:788:ccvaxa:57900004:000:1364
Nf-From: ccvaxa.UUCP!aglew    Dec 10 23:17:00 1987


..> Speed of dump vs. rdump

You're all talking around the problem of synchronous I/O,
if your network has sufficient thruput but excessive
latency to use synchronously.

In 4.3 dump has been changed to use multiple processes
and acheive a facsimile of asynchronous I/O, but I doubt
that rdump has. What we really need are asynchronous
I/O facilities in UNIX, so that the person who wants to
do things at the maximum thruput rate can do so without
having to mess with multiple processes. HP's contention that
asynch I/O isn't needed because it can be acheived with
multiple processes and shared memory doesn't hold water
(especially if you're me, and do a lot of I/O intensive
work, and are always pressing against your process limits).

Asynchronous I/O primitives should basically look like this:

IOtransT aread(fd,buf,n)	- initiate a read
IOtransT awrite(fd,buf,n)	- initiate a write
iowait(n,iolist)		- wait for ios to complete

With operations to guarantee sequentiality, or sometimes not.


Andy "Krazy" Glew. Gould CSD-Urbana.    1101 E. University, Urbana, IL 61801   
aglew@mycroft.gould.com    ihnp4!uiucdcs!ccvaxa!aglew    aglew@gswd-vms.arpa
   
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.