Re: fsync in glib/gio

[Alexander Larsson <alexl redhat com>]

On Fri, 2009-03-13 at 18:20 -0600, Federico Mena Quintero wrote:
> On Fri, 2009-03-13 at 22:16 +0100, Alexander Larsson wrote:
> 
> > Its well explained in the various discussions about this. Essentially,
> > the metadata for the rename is written to disk, but the data in the file
> > is not (yet, due to delayed allocation) and then the system crashes. On
> > fsck we discover the file is broken (no data) and set the file size to
> > 0.
> 
> This reminds me a lot of
> http://bugzilla.gnome.org/show_bug.cgi?id=562396 - a problem with
> Nautilus metadata.  You start a copy operation, but if you do a read
> before the copy is done, then you get the "old" data.  You should wait
> for the copy to be done first, but anyway, my point is...
> 
> My point is that the kernel could perfectly well ensure that metadata
> operations that depend on data operations will not be reordered.  "Don't
> rename a file in a directory if we have outstanding writes for the
> inode", or something.  (After the rename, do you need to open the
> directory and fsync it?  You can't open directories for writing...)

It could, but that is a high cost for filesystem performance, so its not
always there (e.g. in XFS) or an optional (possibly enabled by default).

I don't think the directory fsync matters to get a safe save, if the
directory metadata is not written we would get the old file. There is no
risk in destroying both file if directory metadata is not written. Of
course, if you want to guarantee it on disk you need to fsync the
directory too.