On 2018-09-18 14:16, Andrei Borzenkov wrote:
18.09.2018 08:37, Chris Murphy пишет:
On Mon, Sep 17, 2018 at 11:24 PM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
18.09.2018 07:21, Chris Murphy пишет:
On Mon, Sep 17, 2018 at 9:44 PM, Chris Murphy <li...@colorremedies.com> wrote:
https://btrfs.wiki.kernel.org/index.php/FAQ#Does_grub_support_btrfs.3F
Does anyone know if this is still a problem on Btrfs if grubenv has
xattr +C set? In which case it should be possible to overwrite and
there's no csums that are invalidated.
I kinda wonder if in 2018 it's specious for, effectively out of tree
code, to be making modifications to the file system, outside of the
file system.
a. The bootloader code (pre-boot, not user space setup stuff) would
have to know how to read xattr and refuse to overwrite a grubenv
lacking xattr +C.
b. The bootloader code, would have to have sophisticated enough Btrfs
knowledge to know if the grubenv has been reflinked or snapshot,
because even if +C, it may not be valid to overwrite, and COW must
still happen, and there's no way the code in GRUB can do full blow COW
and update a bunch of metadata.
So answering my own question, this isn't workable. And it seems the
same problem for dm-thin.
There are a couple of reserve locations in Btrfs at the start and I
think after the first superblock, for bootloader embedding. Possibly
one or both of those areas could be used for this so it's outside the
file system. But other implementations are going to run into this
problem too.
That's what SUSE grub2 version does - it includes patches to redirect
writes on btrfs to reserved area. I am not sure how it behaves in case
of multi-device btrfs though.
The patches aren't upstream yet? Will they be?
I do not know. Personally I think much easier is to make grub location
independent of /boot, allowing grub be installed in separate partition.
This automatically covers all other cases (like MD, LVM etc).
It actually is independent of /boot already. I've got it running just
fine on my laptop off of the EFI system partition (which is independent
of my /boot partition), and thus have no issues with handling of the
grubenv file. The problem is that all the big distros assume you want
it in /boot, so they have no option for putting it anywhere else.
Actually installing it elsewhere is not hard though, you just pass
`--boot-directory=/wherever` to the `grub-install` script and turn off
your distributions automatic reinstall mechanism so it doesn't get
screwed up by the package manager when the GRUB package gets updated.
You can also make `/boot/grub` a symbolic link pointing to the real GRUB
directory, so that you don't have to pass any extra options to tools
like grub-reboot or grub-set-default.
