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

[Hugo Mills <hugo@carfax.org.uk>]

On Thu, Jan 06, 2022 at 01:06:40PM -0700, Chris Murphy wrote:
> On Thu, Jan 6, 2022 at 1:02 PM Chris Murphy <lists@colorremedies.com> wrote:
> >
> > On Thu, Jan 6, 2022 at 3:28 AM Filipe Manana <fdmanana@kernel.org> wrote:
> > >
> > > On Thu, Jan 6, 2022 at 10:21 AM Hugo Mills <hugo@carfax.org.uk> wrote:
> > > >
> > > > > Yep, that's correct Hugo.
> > > > >
> > > > > Starting with 3.17, the example on the wiki needs an fsync on
> > > > > "file.tmp" after writing to it and before renaming it over "file".
> > > > > I.e. the full example should be:
> > > > >
> > > > > ****
> > > > > echo "oldcontent" > file
> > > > >
> > > > > # make sure oldcontent is on disk
> > > > > sync
> > > > >
> > > > > echo "newcontent" > file.tmp
> > > > > fsync 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.
> > > > > ****
> > > >
> > > >    Since I can't find an "fsync" command line tool, I've rewritten the
> > > > example in more general terms, rather than tying it to a specific
> > > > implementation (such as a sequence of shell commands). I note that
> > > > we've got a near-duplicate entry in the FAQ, two items down ("What are
> > > > the crash guarantees of rename?"), that should probably be removed.
> > > >
> > > > Updated entry: https://btrfs.wiki.kernel.org/index.php/FAQ#What_are_the_crash_guarantees_of_overwrite-by-rename.3F
> > > > Candidate for deletion: https://btrfs.wiki.kernel.org/index.php/FAQ#What_are_the_crash_guarantees_of_rename.3F
> > >
> > > There's the xfs_io command from xfsprogs that can be used to trigger
> > > an fsync like this:  xfs_io -c fsync /path/to/file
> > > But it's probably not well known for non-developers.
> > >
> > > Anyway, as it is, it looks perfect to me, thanks!
> >
> >
> > I think it's OK to use pseudo-code. Folks will figure it out. So you
> > can just write it as fsync() and even if you're not using the exact
> > correct syntax it'll be understood.
> 
> Topical xxample:
> https://lore.kernel.org/linux-xfs/6A65F394-C1BA-4339-AC9B-051885D12F65@corp.ovh.com/

   I did wonder whether to write it as C-ish code, but I felt that the
prose description was sufficient, and didn't presuppose any particular
implementation.

> Reminds me to ask Filipe if the example Hugo is writing up also needs
> an fsync() on the enclosing directory *after* the rename?

   As I understand it, as long as the data is fsynced properly before
the move, the semantics are safe and atomic (if you don't get the new
data afterwards, you get the old data, regardless of where the crash
is). Syncing the directory and waiting for that to complete gives you
the guarantee that you'll get the new data from that point on of the
system crashes afterwards.

   Hugo.

-- 
Hugo Mills             | I hate housework. You make the beds, you wash the
hugo@... carfax.org.uk | dishes, and six months later you have to start all
http://carfax.org.uk/  | over again.
PGP: E2AB1DE4          |                                           Joan Rivers