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

[Filipe Manana <fdmanana@kernel.org>]

On Wed, Jan 05, 2022 at 06:04:38PM +0000, Filipe Manana wrote:
> 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.

After some digging in git history:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d875f95da43c6a8f18f77869f2ef26e9594fecc

So that guarantee existed until August 2014.

Not anymore, and no one should rely on it (except when using "-o flushoncommit").

> 
> 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