Re: fsync in glib/gio

[Mark Mielke <mark mark mielke cc>]

Alexander Larsson wrote:
> Of course, given that POSIX allows this behaviour we should 
> probably use the fsync hammer to make the risks for data loss less at
> least in some cases. But to argue that such behaviour from the
> filesystem is *good*. It boggles the mind.
>
> Anyway, this argument is over for me. XFS has long had problems with
> this but they have now changed so that rename overwrite is safe (they
> even verify this in their QA runs these days), ext4 will have patches
> for this in 2.6.30, and the btrfs maintainer said he will queue similar
> patches for 2.6.30. Well probably add the fsync to glib saving in the
> "file already exists" case in order to protect against this on other
> systems, but the main future linux filesystems at least are sane in
> their default configurations.
>   

I think we agree more than disagree on the principles. That is, fsync() 
is a sort of hammer, but it probably should be used to explicitly ensure 
that operation is safe, even on systems that do not have built-in 
protection for this particular sequence of operations.

The part we disagree on, I think, is the best course of action. Fighting 
with each file system provider to provide a guarantee not listed in the 
spec, is going to be painful whether you are right or wrong.

I somewhat liked the ReiserFS approach - although I never used it 
myself. I believe they allowed you to demarcate transaction boundaries 
and commit the whole transaction or not at all. This has less of the 
baggage that comes with fsync(), and makes the intent of the application 
clear to the file system. This even works for more complicated 
situations than the rename() case people are fussing over. All 
non-standard extensions of course. If you really feel that the current 
behaviour is wrong - the best approach would be to change the spec.

Cheers,
mark

--
Mark Mielke <mark mielke cc>