Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!panda!teddy!jpn
From: jpn@teddy.UUCP (John P. Nelson)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.databases
Subject: Re: O_SYNC option in SVR3 open system call
Message-ID: <3490@teddy.UUCP>
Date: Thu, 13-Nov-86 15:18:25 EST
Article-I.D.: teddy.3490
Posted: Thu Nov 13 15:18:25 1986
Date-Received: Thu, 13-Nov-86 22:02:57 EST
References: <5922@gatech.EDU> <9119@sun.uucp>
Reply-To: jpn@teddy.UUCP (John P. Nelson)
Organization: GenRad, Inc., Concord, Mass.
Lines: 19
Xref: mnetor comp.unix.questions:39 comp.unix.wizards:56 comp.databases:8

>> 	O_SYNC	When opening a regular file, this flag affects subsequent
>> 		writes.
>>
>> Does anybody out there knows if this wait is for real or is the same BSD
>> idea of the "fflush" in which blocks are merely "scheduled" and the call 
>> returns as if they were actually written to the device. 
>
>The wait is for real.  But what is this "same BSD idea of the 'fflush'"?

I assume that the original author meant fsync(2), not fflush(3).  Fsync
takes a UNIX descriptor, and causes all blocks associated with a file
to be scheduled for write, but unfortunately, does not wait for the
physical writes to complete (the blocks may still be queued in the driver
at the time that fsync returns).  This means that there is no truly reliable
way to assure that a file is synced (say, before say deleting a backup).

The original question was, does the System V O_SYNC wait for PHYSICAL I/O
to complete, or does it just avoid having any unwritten buffers in the
buffer pool (NOT necessarily the same thing!).