Re: fsync in glib/gio

[Mark Mielke <mark mark mielke cc>]

Mark Mielke wrote:
> Putting fsync() on close() is a hack.

Hmm - Looking at the patch, I don't see it doing fsync() on close() - I 
should have read from the beginning instead of reacting to the one 
person calling the file system semantics broken. :-)

Definitely - any file system operations that *requires* file system 
integrity, should make use of fsync(). The "write new file and rename 
into place" is a good candidate, and fsync() should definitely be done 
here. Wishful thinking about some theoretical system which is both 
efficient, deployed on all systems everywhere, and does fully 
synchronous writes for both data and metadata is pointless. :-)

Note that this doesn't matter what file system is used. Older 
non-journalled file systems had the same problem. The only file systems 
that are completely safe are the ones that do full journalling of all 
data. (Those also tend to be the slowest file systems or modes although 
some file systems may be breaking this trend...)

Just please don't *always* fsync(). Only where it matters. As per the 
patch, I think it tries to do it where it matters and looks fine?

Cheers,
mark

--
Mark Mielke <mark mielke cc>