Re: fsync in glib/gio

[Alexander Larsson <alexl redhat com>]

On Tue, 2009-03-24 at 11:09 +0100, Xavier Bestel wrote:
> On Tue, 2009-03-24 at 10:38 +0100, Pavel Machek wrote:
> > > > > One compromise we could make it to only fsync in the case we're actually
> > > > > overwriting an existing file. This would mean that we don't risk
> > > > > loosing
> > > > 
> > > > You should fsync just before doing rename, preferably in some special
> > > > way so that we can tell it apart from 'normal' fsync.
> > > 
> > > This is what I mean of course. And there is no such "special way"
> > > infortunately.
> > 
> > One proposal was to create "replace()" call (doing proper replacement
> > of one file with another). It could start up as "fsync(); rename()"
> > initially, but it should slowly move up into glibc and kernel, and do
> > the right thing.
> 
> Isn't that a bit heavyweight ? The minimal thing needed would be a sort
> of barrier, to ensure the file state is coherent before and after the
> rename() - i.e. replace()+unlink() shouldn't do more io than unlink().

The idea is of course that replace() would eventually be replaced with
something that did less when that is availible.

> IMHO the kernel should guarantee a safe rename() (more that the minimal
> posix requirement) with either the old or new file on disk. But maybe
> that's too hard to fix.

Just because some kernel guarantees this doesn't mean that glib can rely
on that though.