On Mar-18, Dan Sugalski wrote: > At 9:57 PM +0000 3/18/03, Nicholas Clark wrote: > >Oops. This turned into a ramble. "flush" ne "sync". If both are needed in > >different places, provide both as distinct methods. > > Valid point though. We need both a flush and a sync, since we can't > be sure that what's living underneath an io handle is a real file. > 'Kay, sync and flush are both on the list. > --
I agree with the need for both, or at least the need for flush to not call fsync. The zlib example is a good one, but I wanted to mention that the issue exists and is significant even when using vanilla file I/O. fsync is slow and rarely necessary or useful. If I write to a temp file and then run a subprocess that uses that temp file, then I just want the subprocess to see what I wrote. I don't care if it ever makes it to disk -- and would usually prefer that it didn't, because I'm going to delete the file soon after. Anyway, there are many ways that fsync can return before the data actually makes it to permanent storage (disk drive write caching, for example.) So you should only use it when you know what you're doing and can safely make certain assumptions about the system you're running on.
