grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ZFS grubenv write support


From: Daniel Kiper
Subject: Re: ZFS grubenv write support
Date: Fri, 17 Jan 2020 13:10:06 +0100
User-agent: NeoMutt/20170113 (1.7.2)

Hi Paul,

On Mon, Jan 13, 2020 at 04:03:34PM -0800, Paul Dagnelie wrote:
> Hey all,
>
> I'm interested in trying to enable support for boot-time modification of
> the grubenv file on ZFS and other non-standard filesystems that don't
> necessarily work today. I have a proposed design, and I was wondering if
> you all would be interested in it. I'd be implementing it and testing it
> myself, my main goal was to try to make sure that after doing so, the
> community would be interested in integrating it. This has the dual
> advantage of allowing everyone using ZFS and other filesystems to benefit
> from it, and also making it so I don't have to maintain a fork indefinitely.
>
> The proposal is that rather than always opening the grubenv file and
> reading it using the normal file API, we can add a function (or functions)
> to the fs struct that allows a filesystem to advertise that it needs to use
> special logic to handle writable files. Then the grubenv file can be stored
> in a special location (probably one of that padding areas in the label,
> which is where the FreeBSD loader stores some boot data in zfs) where it
> can be written safely by the bootloader without harming the checksum tree
> in ZFS. The GRUB code would need to change to invoke the special "Please
> let the fs handle this writable file" logic (which would have open, read,
> and write functions) for filesystems that have them available, but this
> should be extensible to other CoW or sparse filesystems like BTRFS. If a
> filesystem doesn't advertise that logic, GRUB would fall back to using the
> currently file-based logic.

In general I like the idea. Though I would like to have this
configurable by user if possible (some FSes may support traditional
grubenv and special regions for boot loaders). I would also take into
account Luiz's comments. UEFI variables? Seems interesting at first
sight. Though it may have some limitations.

> An alternative proposal that I found slightly less elegant but would
> involve fewer invasive changes is to just modify the zfs grub logic to
> check if it's opening the grubenv file, and if so divert to special read
> and open logic that would access this padding area. This would involve
> hardcoding the grubenv file name in the ZFS code, but I figured I would
> mention it as a possibility in case it was preferred for other reasons.

Please do not do that.

And please CC relevant FS people if you post patches.

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]