Re: fsync in glib/gio

[Mark Mielke <mark mark mielke cc>]

Stef Walter wrote:

Mark Mielke wrote:
  

I think fsync() is absolutely necessary to be explicit in this
situation, because the application needs to assert that all data is
written *before* using rename to perform the atomic-change-in-place
effect. I think that anybody who thinks fsync() is unnecessary is
failing to see the principle that fsync() exists solely for the purpose
of guaranteeing this state, and that if you think fsync() should be
unnecessary here, you should also think fsync() should be unnecessary
anywhere else. Why have an fsync() at all? Why shouldn't all operations
be synchronous by nature? Change the specification to force all I/O
operations to be ordered that way no application developer will ever
have to be surprised or ever call a synchronization primitive again. Right?
    

fsync() was really broken on ext3. Now, all of a sudden it's "teh
awesome!!!! FTW!!!"

There's a reason people haven't been using it. It could take an obscene
amount of time to complete depending on what you happened to be doing in
elsewhere in the (multi-tasking, no less) OS.
  

This depends on what your priority is. If your priority is to be absolutely certain that the file be intact on power failure - then you really have no other option.

Most people have not had this requirement in the past.

The rename to effect atomic-change-in-place is a scenario where you want a stronger guarantee. It's not about fsync() being "awesome" - it's about it being necessary to achieve this guarantee in a portable way - whatever the cost.

Cheers,
mark

-- 
Mark Mielke <mark mielke cc>