Re: fsync in glib/gio

[Alexander Larsson <alexl redhat com>]

On Sat, 2009-03-14 at 13:38 -0400, Mark Mielke wrote:

> Should sed -i use fsync()? If it 
> is promising atomic-change-in-place, then it certainly should.

This is the same kind of reasoning that says its ok to do something
because its specified by posix. If its not defined somewhere that sed -i
must use fsync, is it then ok to lose users data. Its certainly per the
spec, but its a pretty sucky system that I wouldn't want to use.

> Also, if the user chooses a file system which makes fewer guarantees 
> during a "pull the plug" test, they should be willing to live with their 
> choices. In ext2 days and FAT16/32 days, the effects could be very bad.

Sure, way back we had even crappier software. This shouldn't be the
reason to not hold todays standard higher in the robustness area.

> This thread has focused on the rename() case, often used to have the 
> atomic-change-in-place effect. There are other cases that even your most 
> favourite file system mode may not "protect" you from. Most file systems 
> won't guarantee a write() order to disk, as I listed before.

We focus on that one because its of increadible important, being the
historical way that one implements save on unix (witness e.g. gnu sed
using it for in-place replace), and its a pretty simple common
operation. If you do all sorts of weird database or mmap operations
everyone expects that you have to handle these details. Especially,
nobody ever assumed the filesystem was a database or that it provides
ACID guarantees. Please don't use such strawman arguments.

We all understand that its is per-spec to not guarantee
data-before-metadata on rename, we're not stupid and able to read a
manpage as well as you. But we still think its a bad idea and not a sign
of robust software.