Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.wizards
Subject: Re: UNIX semantics do permit full support for asynchronous I/O
Message-ID: <29290:Aug3120:10:5590@kramden.acf.nyu.edu>
Date: 31 Aug 90 20:10:55 GMT
References: <60345@lanl.gov> <27619@nuchat.UUCP> <1990Aug30.222226.20866@cbnewsm.att.com>
Distribution: usa
Organization: IR
Lines: 23

In article <1990Aug30.222226.20866@cbnewsm.att.com> lfd@cbnewsm.att.com (leland.f.derbenwick) writes:
> In article <27619@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes:
> > Have read(2) and write(2) calls map the pages containing the buffers
> > out of the user address space and return immediately.  Once the
> > data have been copied (DMAed?) to/from the buffers, map the pages back in.
> Apart from the implementation problems that others have mentioned,
> _this suggestion breaks existing code_.

No, it does not. On many paged machines, an implementation of Steve's
suggestion takes virtually [sic] no time. The worst that happens is your
original efficiency. The best that happens is a noticeable speedup,
especially of pipe read-writes. A program that uses, say, a getpage()
call to allocate a page-aligned buffer can guarantee the best case.

> In essentially any serious database application, a completed
> write() to a raw disk is treated as a guarantee that the data
> block has been _physically written to the device_.

No. Any database application that claims to recover after crashes
without fsync()ing its write()s is lying. (This says some interesting
things about certain System V database programs.)

---Dan