Re: fsync in glib/gio

[Alexander Larsson <alexl redhat com>]

On Fri, 2009-03-13 at 14:34 -0700, Brian J. Tarricone wrote:

> 
> > 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.
> 
> Sure, but that's just a special case.  So you (as the app developer) 
> recognise this, understand how the spec interacts with your use-case, 
> and write robust code accordingly.
> 
> Or, you take the "the spec/kernel/FS is broken" approach, and try to get 
> a guarantee specified for the special case, something like "in the case 
> where a file is renamed over top of an existing file, the source file 
> must be flushed to disk before the rename takes place."  And then the 
> app developer doesn't have to worry about it, because the implementation 
> should do the right thing.

I think you are conflating two issues.

1) Should glib/gio fsync at least in the really bad data loss case to
make sure users are not losing data on such filesystem

2) such filesystems are broken

Clearly the answer to 1 is yes. Anything else would be a disservice to
our users data. However, that doesn't mean such filesystems aren't
broken, in the sense that I would never let a filesystem like that near
any of my data.

For instance, any script doing sed -i s/foo/bar/ file.conf on such a
filesystem risks ending up with a zero byte file.conf. (sed uses rename
but doesn't fsync.) Is this what users except? Should that script be
rewritten in C so it can use fsync? Should sed fsync? That kind of
reasoning will lead to all apps implementing fsync-on-close manually,
and we're then worse off than if the fs just guaranteed
data-before-metadata-on-rename.

> Yeah, I'd totally agree.  But in the absence of an ability to change the 
> spec, it's best to try to make things work as well as they can within 
> the spec, no?  It seems like some people are advocating "well, today 
> everyone uses ext3, and there's no problem, so we shouldn't do this 
> because it'll reduce performance there."  And of course, a year from now 
> (or less!  obviously some already are), I'm sure most desktop distros 
> will be shipping with ext4 default.  (And I could be wrong, but it seems 
> to me that ext3 is the only FS that, by coincidence will usually be 
> immune to this problem, and, also coincidentally, is one of the only 
> FSes that has crappy fsync() performance.)

ext4 from the next kernel release will have patches that makes the
rename case safe, although it will be an option that can be disabled.
Not sure about btrfs. Its unsafe at the moment, but chris mason is
talking about possible fixes in the lwn thread.