Re: fsync in glib/gio
- From: Alexander Larsson <alexl redhat com>
- To: Xavier Bestel <xavier bestel free fr>
- Cc: gtk-devel-list gnome org, Sven Neumann <sven gimp org>, Pavel Machek <pavel ucw cz>
- Subject: Re: fsync in glib/gio
- Date: Tue, 24 Mar 2009 11:57:42 +0100
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.
] [Thread Prev