gerardo@gatech.EDU (Gerardo Brenes) (11/09/86)
Subject: SVR3 open with O_SYNC option
Newsgroups: comp.unix.questions
Keywords: really waits for physical update?
In the reference manual for SVR3 for the ATT 3B2 machine, the description for
the open system call mentions an option O_SYNC. It literally says:
O_SYNC When opening a regular file, this flag affects subsequent
writes. If set, each write (2) will wait for both the file
data and file status to be physically updated.
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.
Please use e-mail to answer and I'll post a summary of comments if enough
interest is shown. Thanks a lot for your help.
Gerardo Brenes
================================================================================
Smile ! They might think you are nuts and just go along with it!
================================================================================
School of Information & Computer Science, Georgia Tech, Atlanta GA 30332
CSNet: gerardo@GATech
ARPA: gerardo%GATech.CSNet@CSNet-Relay.ARPA
uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!gerardo
================================================================================guy@sun.uucp (Guy Harris) (11/10/86)
> O_SYNC When opening a regular file, this flag affects subsequent > writes. If set, each write (2) will wait for both the file > data and file status to be physically updated. > > 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'"? First of all, "fflush" is a part of standard I/O, and if you do an "fflush" it ends up doing "write" calls, so the notion of a delayed or asynchronous write is *not* a property of "fflush", but a property of "write". Second, "fflush" isn't a "BSD idea" at all; it, like a lot of other things in 4BSD, dates back to V7 (actually, it dates back even further than that) and, as such, should be called an "AT&T idea". Third, the notion of a delayed or asynchronous write also considerably predates even 1BSD. Finally, there *is* a "BSD idea" relating to this; however, it is the idea of an "fsync" call to flush blocks to the device, and it *does* wait (for real) until the blocks are actually written to the device. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
jrw@hropus.UUCP (Jim Webb) (11/12/86)
> > O_SYNC When opening a regular file, this flag affects subsequent > > writes. If set, each write (2) will wait for both the file > > data and file status to be physically updated. > > > > 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. And this has been an (albeit undocumented) flag in all vax and 3bx versions of AT&T System V. Not to go into too much detail (my hands would get probably get crushed instead of just slapped ;-) but the kernel has two write routines, one that just schedules the disk block to be written and another that waits for the actually writing before returning. If O_SYNC is set, then the former is called. To find out whether your version of UNIX supports this, grep for SYNC in /usr/include/sys/file.h. That will give you the octal value of the flag, if it is available. Then, I guess to see if the kernel recognizes it, time writes with and without the O_SYNC flag set. The latter writes should be a good bit faster. -- Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw "Use the Force, Read the Source"
jpn@teddy.UUCP (John P. Nelson) (11/13/86)
>> 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!).