Xref: utzoo comp.lang.misc:5440 comp.unix.internals:13
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.lang.misc,comp.unix.internals
Subject: Re: UNIX semantics do permit full support for asynchronous I/O
Message-ID: <556:Aug3122:09:3290@kramden.acf.nyu.edu>
Date: 31 Aug 90 22:09:32 GMT
References: <861@dg.dg.com> <12023:Aug3017:24:1590@kramden.acf.nyu.edu> <1990Aug31.190751.12522@dg-rtp.dg.com>
Distribution: usa
Organization: IR
Lines: 23

In article <1990Aug31.190751.12522@dg-rtp.dg.com> eliot@dg-rtp.dg.com writes:
> I think this point very well covers the case of writing:  if you want
> to be sure it really got to disk, you need to do an fsync(), and even
> then I'm not sure you can be sure (doesn't the fsync just *mark* the
> buffers for writing out?).  We could certainly arrange for fsync to
> block until everything is really on disk.

fsync() will certainly do that, independently of this mechanism. (It's
sync() that just marks buffers for writing. BSD's fsync() truly writes
the data to disk, giving the transaction control you need for reliable
databases. I have no idea what you poor System V folks do.)

> But consider the reading case.
  [ what happens upon failure? ]

As Peter pointed out, this case is fatal. How many disk errors have you
had over the last year? How many did the programs involved recover from?
Yeah, thought so.

I guess you're right in principle: Steve's proposal is only completely
transparent for writing (which is the more important case anyway).

---Dan