In message <009e01c17938$7b523880$0100a8c0@snowdrop>, "David Laight" writes:
>> > I wonder if a close() of the last descriptor to a file should do an implic
>it
>> > flush()
>> 
>> If you mean fsync(), then no.
>
>How much of a performance hit would scheduling the write of blocks associated
>with a file (including the inode) when the file is closed actually be?
>
>I suspect that these writes will have to be done anyway!
>Clearly there is no need to do them synchronously on the close.
>
>FYI adding:
>
>all:    sync <targets>
>        sync
>
>sync:
>        sync
>
>to a makefile tends to protect your source files...

Your source files shouldn't be affected by that, unless the previous 
step is to extract them from a tarball.  It's only very 
recently-written stuff that's at risk.

Anyway -- excess syncs can be a tremendous load on a busy system.  At 
least in some cases, a file will be deleted and its blocks reallocated 
and reused before they're written out.  In that case, there was no need
to flush them to disk.  (If memory serves, sendmail used to have 
tremendous performance problems because it fsync'ed queue files 
frequently.)


		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com