Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!usc!snorkelwacker!bloom-beacon!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.internals Subject: Re: UNIX semantics do permit full support for asynchronous I/O Message-ID: Date: 3 Sep 90 09:00:43 GMT References: <60345@lanl.gov> <27619@nuchat.UUCP> <1990Aug30.222226.20866@cbnewsm.att.com> <29290:Aug3120:10:5590@kramden.acf.nyu.edu> <27820@nuchat.UUCP> Sender: bzs@world.std.com (Barry Shein) Distribution: usa Organization: The World Lines: 27 In-Reply-To: steve@nuchat.UUCP's message of 2 Sep 90 18:06:04 GMT From: steve@nuchat.UUCP (Steve Nuchia) [responding to my note] >>Do there exist any benchmark or other test results which indicate that >>adding asynch i/o to unix actually yields a performance improvement? > >There is little question that it can dramatically speed up selected >applications. I guess that's a way of saying "no, I don't know of any results..." >Applications, mostly in the backup arena (afio, ddd) >get substancially improved throughput even using really stupid mechanisms. Backups almost always use raw I/O, how does this affect this observation? Is it worth doing for filesystem (disk) I/O? Why are these mechanisms "stupid"? Are you sure the same speed-up would be seen with async I/O? Are there any other applications besides intensive disk to tape which would benefit from this, or might this be a singular example? -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD