Re: fsync in glib/gio

[Federico Mena Quintero <federico novell com>]

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...)

  Federico