Xref: utzoo comp.unix.wizards:8294 comp.os.misc:427
Path: utzoo!mnetor!uunet!husc6!tut.cis.ohio-state.edu!triceratops.cis.ohio-state.edu!karl
From: karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
Newsgroups: comp.unix.wizards,comp.os.misc
Subject: Re: Uses for access time, stuff in inodes
Message-ID: <12606@tut.cis.ohio-state.edu>
Date: 6 May 88 14:45:35 GMT
References: <2059@rtech.UUCP> <3672@lynx.UUCP> <10613@steinmetz.ge.com> <577@minya.UUCP>
Sender: news@tut.cis.ohio-state.edu
Distribution: na
Lines: 16

daveb@llama.rtech.UUCP says...
   It would be nice if there were some way for
   O_SYNCed files to avoid [2 writes/call]: maybe just defer the
   access/mod time write until the file is closed.

I would disagree.  If data blocks are updated but the inode is left
in-core-only, what value have I gained by using O_SYNC?  If the system
crashes right now, with half a megabyte of data written, but no record
of the changes to the inode yet out to disc, O_SYNC has become
useless.

I tend to think that O_SYNC is specifically intended for those folks
who are explicitly willing to put up with the performance hit of 2
physical writes/call.

--Karl