Re: Does GRUB btrfs support log tree?

[David Sterba <dsterba@suse.cz>]

On Sun, Oct 27, 2019 at 09:05:54PM +0100, Chris Murphy wrote:
> > > Since log tree writes means a
> > > full file system update hasn't happened, the old file system state
> > > hasn't been dereferenced, so even in an SSD + discard case, the system
> > > should still be bootable. And at that point Btrfs kernel code does log
> > > replay, and catches the system up, and the next update will boot the
> > > new state.
> > >
> > > Correct?
> > >
> >
> > Yes. If we speak about grub here, it actually tries very hard to ensure
> > writes has hit disk (it fsyncs files as it writes them and it flushes
> > raw devices). But I guess that fsync on btrfs just goes into log and
> > does not force transaction. Is it possible to force transaction on btrfs
> > from user space?

* sync/syncfs
* the ioctl BTRFS_IOC_SYNC (calls syncfs)
* ioctls BTRFS_IOC_START_SYNC + BTRFS_IOC_WAIT_SYNC

> The only fsync I ever see Fedora's grub2-mkconfig do is for grubenv.
> The grub.cfg is not fsync'd. When I do a strace of grub2-mkconfig,
> it's so incredibly complicated. Using -ff -o options, I get over 1800
> separate PID files exported. From what I can tell, it creates a brand
> new file "grub.cfg.new" and writes to that. Then does a cat from
> "grub.cfg.new" into "grub.cfg" - maybe it's file system specific
> behavior, I'm not sure.
> 
> I'm pretty sure "sync" will do what you want, it calls syncfs() and
> best as I can tell it does a full file system sync, doesn't use the
> log tree. I'd argue grub-mkconfig should write all of its files, and
> then sync that file system, rather than doing any fsync at all.

This would work in most cases. I'm not sure, but the update does not
seem to be atomic. Ie. all old kernels match the old grub.cfg, or there
are new kernels that match the new cfg.

Even if there's not fsyncs and just the final sync, some other activity
in the filesystem can do the sync before between updates of kernels and
grub.cfg. Like this

start:

- kernel1
- grub.cfg (v1)

update:

- add kernel2
- remove kernel1
- <something calls sync>
- update grub.cfg (v2)
- grub calls sync

If the crash happens after sync and before update, kernel1 won't be
reachable and kernel2 won't be in the grub.cfg.