Re: [bug] GNOME loses all settings following failure to resume from suspend

[Filipe Manana <fdmanana@kernel.org>]

On Wed, Jan 05, 2022 at 10:34:10AM -0700, Chris Murphy wrote:
> https://gitlab.gnome.org/GNOME/dconf/-/issues/73
> 
> Following a crash, instead of either the old or new dconf database
> file being present, a corrupt one is present.
> 
> dconf uses g_file_set_contents() to atomically update the database
> file, which effectively inhibits (one or more?) fsync's, yet somehow
> in the crash/powerfail case this is resulting in a corrupt dconf
> database. I don't know if by "corrupt" this is a 0 length file or some
> other effect.

Looking at the issue, Sebastian Keller posted a patch to disable one
optimization in glib, that should fix it.

Looking at the code before that patch, it explicitly skips fsync after
a rename pointing out to:

https://btrfs.wiki.kernel.org/index.php/FAQ#What_are_the_crash_guarantees_of_overwrite-by-rename.3F

I'm afraid that information is wrong, perhaps it might have been true in
some very distant past, but certainly not for many years.

The wiki says, doing something like this:

   echo "oldcontent" > file

   # make sure oldcontent is on disk
   sync

   echo "newcontent" > file.tmp
   mv -f file.tmp file

   # *crash*

Will give either:

file contains "newcontent"; file.tmp does not exist
file contains "oldcontent"; file.tmp may contain "newcontent", be zero-length or not exists at all.

However that's not true, there's a chance 'file' will be empty.

During a rename with overwrite we trigger writeback (via filemap_flush())
of the file being renamed but never wait for it to complete before
returning to user space. So what can happen is:

1) We trigger writeback;

2) We join the current transaction and do the rename;

3) We return from rename to user space with success (0);

4) Writeback didn't finish yet, or it has finished but the
   ordered extent is not yet complete - i.e. btrfs_finish_ordered_io()
   did not complete yet;

5) The transaction used by the rename is committed;
   A transaction commit does not wait for any writeback or in flight
   ordered extents to complete - except if the fs is mounted with
   "-o flushoncommit";

6) Crash

After mounting the fs again 'file' is empty and 'file.tmp' does not exists.

The only for that to guarantee 'file' is not empty and has the expected
data ("newcontent"), would be to mount with -o flushoncommit.

I don't think I have a wiki account enabled, but I'll see if I get that
updated soon.

Thanks.

> 
> Thanks,
> 
> -- 
> Chris Murphy