Re: fsync in glib/gio

[Michael Meeks <michael meeks novell com>]

On Thu, 2009-03-12 at 21:11 +0100, Alexander Larsson wrote:
> With all the recent yahoo about ext4 data loss and fsync I felt I had to
> look at glib and make sure we're doing this right.

	Hmm; is this not just a database guy ? ;-) presumably if -all- file I/O
should be synchronous, the kernel would do this for us ?

> Attached is a patch that makes sure we fsync before closing in the gio
> file saving code and in g_file_set_contents().

	Isn't it the case that with ext3 and below fsync is an impossibly
expensive operation that gums up the whole system - by taking some
obscure kernel lock on some other piece of somethingummy and causes
everything to grind to a halt, your audio to skip, and instant hair
loss ? ;-)

	I believe they fixed this for ext4, which is nice for them; but ... for
everyone else ? What data-loss case are we really trying to protect
against ? of course, if you hard yank the power, bad things can happen;
but how often does that occur ?

	The suspend / resume example is fairly lame; what distro does not do a
'sync' before suspend to RAM / disk ?

	AFAIR we spent some cycles in evolution recently to reduce the
ridiculous number of fsync's that sqlite was injecting into each
transaction to make the message store perform reasonably and not grind
the whole system to a halt ;-) at 10ms per fsync, that makes some sense.

	Regards,

		Michael.

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot