GNOME Bugzilla – Bug 705563
dconf database corruption ...
Last modified: 2013-08-07 13:26:59 UTC
Imagine my surprise when running out of power on the flight back from GUADEC - and hard shutting down the laptop, that when I booted again - my settings were corrupt. Running eg. the terminal (now gone completely white & unusable) - I couldn't change any setting; using dconf-editor I got this on the console: (dconf-editor:4028): dconf-WARNING **: failed to commit changes to dconf: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code17: Cannot open dconf database: invalid gvdb header Which is rather a pain - with naturally rather a screwed up session. IMHO it would be good to check this during login and prompt / bail gracefully. Even better would be to do the right fsyncs / atomic rename (etc.) [ I assume we do but ... ] to not corrupt the data. My file-system is 'ext4' my kernel (after reboot) is: Linux linux-d2lh.site 3.7.10-1.16-pae #1 SMP Fri May 31 20:21:23 UTC 2013 (97c14ba) i686 i686 i386 GNU/Linux I assume it was the same beforehand; I have dconf-0.16.1 on openSUSE 12.3 The my home directory is on: /dev/sda3 on /data type ext4 (rw,relatime,data=ordered) I attach the file full of zeros which was the result of this: -rw-r--r-- 1 michael users 59407 Aug 5 21:58 user That time -might- be around when I lost power; but I was doing nothing except editing in emacs and/or using evolution for mail at the time - at least, nothing that I would imagine would be changing settings frequently enough to cause grief.
Created attachment 250965 [details] dconf 'user' file from ~/.config/dconf/
This was caused by a short period of time in GLib where we removed the fsync() on g_file_set_contents() when we detect ext4, on the basis of the ext4 documentation saying that this is no longer a problem. Turns out that it was still a problem. To make matters worse, the changes were made on an unstable branch but accidentally got cherry-picked into a stable release which made it into distros. We started getting data loss reports pretty quickly.... This resulted in me having a rather long thread with Ted Ts'o on ext4 list: http://www.spinics.net/lists/linux-ext4/msg38774.html He made some further changes to really make it safe, but we already reverted the removal of the fsync() and we're going to keep it that way. One of those "once bitten, twice shy" things.... Sorry about your data :/
Ryan is referring to https://bugzilla.gnome.org/show_bug.cgi?id=701560 See also https://bugzilla.gnome.org/show_bug.cgi?id=702785 for a potential mitigation we could land in gconf. Probably growing less useful over time now that fewer people will have been running the broken GLib, but there are clearly still people hitting it.
s/gconf/dconf/ =)
(In reply to comment #3) > Ryan is referring to https://bugzilla.gnome.org/show_bug.cgi?id=701560 > > See also https://bugzilla.gnome.org/show_bug.cgi?id=702785 for a potential > mitigation we could land in gconf. Probably growing less useful over time now > that fewer people will have been running the broken GLib, but there are clearly > still people hitting it. Well, everybody having the latest glib stable release will have it (it's part of glib 2.36.3; the revert was done past this release and since then, only 2.37.x releases hit the mirrors. Could we get a 2.36.4 release?
(In reply to comment #5) > (In reply to comment #3) > > Ryan is referring to https://bugzilla.gnome.org/show_bug.cgi?id=701560 > > > > See also https://bugzilla.gnome.org/show_bug.cgi?id=702785 for a potential > > mitigation we could land in gconf. Probably growing less useful over time now > > that fewer people will have been running the broken GLib, but there are clearly > > still people hitting it. > > Well, everybody having the latest glib stable release will have it (it's part > of glib 2.36.3; the revert was done past this release and since then, only > 2.37.x releases hit the mirrors. Oh, shit. Yes, we need a new stable GLib release.