Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!mcnc!rti-sel!dg_rtp!meissner
From: meissner@dg_rtp.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: O_SYNC and filesystem updating
Message-ID: <1165@dg_rtp.UUCP>
Date: Tue, 24-Feb-87 10:33:17 EST
Article-I.D.: dg_rtp.1165
Posted: Tue Feb 24 10:33:17 1987
Date-Received: Fri, 27-Feb-87 06:19:19 EST
References: <11470@gatech.EDU> <12946@sun.uucp> <413@yabbie.rmit.oz>
Reply-To: meissner@dg_rtp.UUCP (Michael Meissner)
Organization: Data General (Languages @ Research Triangle Park, NC.)
Lines: 26

In article <413@yabbie.rmit.oz> rcodi@yabbie.rmit.oz (Ian Donaldson) writes:
> 
> It is not sensible to ensure that *every* write be syncronously updated
> to disk.  To do this would incurr enormous disk overheads.  Picture
> doing a write of 2 bytes here and then 3 bytes there -- both in the same
> disk block -- it requires 2 disk writes to do it.  If it wasn't important
> that the 2 bytes be syncronously written before the 3 bytes then why
> go to the effort to do it?  If it was important, then fine, we must live
> with it.  The thing is, that most times it *isn't* necessary.

Then don't set O_SYNC for that file.  For your typical database with
transactions, writes to the log file must be guaranteed.

> I suppose that you could open the file twice with SVR[23], one
> with O_SYNC and one without to acheive a similar effect, but then you 
> have all sorts of problems if you use a buffered package such as stdio 
> to do I/O on them, unless you use the O_SYNC fd for just flushing
> blocks (even that won't work properly unless you rewrite all the
> blocks you wrote with the non O_SYNC fd).

I believe you can also set O_SYNC on/off with fcntl at any time.  This
avoids the problems you mentioned above.
-- 
	Michael Meissner, Data General	Uucp: ...mcnc!rti-sel!dg_rtp!meissner

It is 11pm, do you know what your sendmail and uucico are doing?