Re: fsync in glib/gio

[Alexander Larsson <alexl redhat com>]

On Fri, 2009-03-13 at 11:11 -0700, Brian J. Tarricone wrote:
> Sven Neumann wrote:
> 
> > It seems wrong to work around broken file-systems on the application
> > level. That only takes away pressure from the file-system developers to
> > address the problem properly.
> 
> How is the file system broken?  Read the man page for write().  If you 
> want to guarantee that file data will hit disk (or at least the disk's 
> HW buffer) by a certain time, you need to call fsync() (or fdatasync(), 
> where available).

The fact that its documented doesn't make it not broken. If you read the
posix specs you'll see that its per specification for the implementation
of fsync() to be empty. 

Now, we don't actually really need the data to be on the disk at a
certain time. On the contrary, its really fine if its delayed. But, what
we want is either the old file in place, or the new file in place, not
the old file deleted, the metadata for the new file and the new file
being empty. Thats what is broken, even if its allowed by POSIX.

> This isn't a Linux idiosyncrasy, even.  POSIX specifies this.
>
> The only thing that's actually broken IIRC is ext3, in that a fsync() 
> effectively acts as a full-FS sync() (see the Firefox 3.0/sqlite 
> fiasco[1]), which is ridiculous.  If anything should be fixed, *that* 
> should be... as well as naive applications that think that open() -> 
> write() -> close() is sufficient to get data to disk in a known amount 
> of time.

Broken is a wider concept than you think. Things that are fully up to
some well documented spec can also be broken from the point of view of
common sense.