On Tue, Nov 12, 2019 at 8:04 PM Goffredo Baroncelli <kreijack@xxxxxxxxx> 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
