Re: fsync in glib/gio
- From: Alexander Larsson <alexl redhat com>
- To: michael meeks novell com
- Cc: Mark Mielke <mark mark mielke cc>, gtk-devel-list gnome org, Morten Welinder <mortenw gnome org>
- Subject: Re: fsync in glib/gio
- Date: Mon, 16 Mar 2009 11:49:16 +0100
On Mon, 2009-03-16 at 10:23 +0000, Michael Meeks wrote:
> On Sun, 2009-03-15 at 10:19 +0100, Alexander Larsson wrote:
> > The debate is far from over with this. gio should be made slower and do
> > unnecessary syncronous I/O in order to fulfill the standards, yes.
>
> Sure, it should fsync on ext4-before-it-was-fixed systems - it sucks to
> loose data; though I'm still unconvinced this is a standards issue :-)
There is no requirements in any standard as to what happens on system
crashes.
> > But there are milllions of lines of code that does the rename as
> > atomic replace and the chances that anywhere near a majority of those
> > are "fixed" is extremely slim. Therefore everyone should be aware of
> > the broken filesystems that don't give data-before-metadata-on-rename
> > guarantees so that sane people can stay away from them.
>
> Out of interest, what distributions are shipping with ext4 configured
> in this helpful "loose your data" mode ? can we not simply inject the
> "go slower" patch into these ext4 distros [ since it won't affect their
> performance quite as badly as everywhere else ], as a temporary
> workaround; and then sit back and let the default glib behaviour be to
> work well on all sane systems ? :-)
It seems both ubuntu and F11 will backport the ext4 fixes. However, even
with these fixed there is risk for data loss on e.g. xfs, and even ext3
if you configure it in data=writeback mode. There was also reports from
nokia about it being unsafe on the flash file system they were using.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]