Re: Does GRUB btrfs support log tree?

[Chris Murphy <lists@colorremedies.com>]

On Tue, Nov 12, 2019 at 8:04 PM Goffredo Baroncelli <kreijack@libero.it> wrote:
>
> On 11/11/2019 20.37, Chris Murphy wrote:
> > Anyway, the lack of a generic (file system independent) way to handle
> > this use case is actually a bit concerning.
>
> I think that a more simpler approach would be developing a GRUB fs, where is the kernel to be adapted to the needing of GRUB...
> So we can lowering the requirement...

I do really agree with this. It seems like a neat idea that a
bootloader can just read any file system, but when it cannot have a
true/complete view of the file system state because it just flat out
ignores critical parts of the file system? Egads.


> The GRUB-fs should have the following main requirements:
> - allow the atomicity guarantee
> - allow molti-disk setup
> - allow grub to update some file (grubenv come me as first)
> - it should require a simple implementation (easy to porting to multiple system, which basically means linux, *bsd and solaris ?)
> - the speed should be not important

Plausibly we're most of the way there already, adapting the existing
"BIOS Boot" partition.

>
>
> Anyway GRUB on BTRFS suffers of a big limitation: GRUB can't update the grubenv file; and until GRUB will learn how update a COW filesystem, this limit will be impossible to avoid (*)

Yep. And I've discussed it with XFS and ext4 devs and they're not keen
on anything writing into file system space outside of their (kernel or
user space repair too) code, which is a reasonable concern. XFS
doesn't have inline extents yet, but it's proposed. ext4 does have
inline extents I think but not enabled by default, and I also think it
takes a non-default inode size to support the ~1KiB typical grubenv
file size: but inline extents would be subject to metadata
checksumming, same as on Btrfs. So in effect, there are valid use
cases that are, or may soon become, invalid for grubenv use as
currently implemented, on the most common Linux file systems.

> (*) Even tough implementing the update of a NOCSUM file should be not so difficult...

So far I've seen 1KiB grubenv is pretty much always an inline extent
on Btrfs. Even if flagged nocow it ends up being subject to leaf
checksum. If GRUB modifies this grubenv, now that whole leaf is
invalid which could mean data loss for things not even related to the
grubenv, depending on what else is in the leaf.

I mean, GRUB is very cool in many ways, but it's so complicated that
maintaining it all I think is a real challenge and concern. And then
on top of that, the various distributions actively fork it into their
own mutually incompatible flavors. It's like GRUB is a set of LEGOs
and everyone can really optionally build their own whatever.

-- 
Chris Murphy