Re: Status of ZFS support on Guix

[Kaelyn <kaelyn.alexi@protonmail.com>]

Hi,

On Tuesday, October 1st, 2024 at 1:23 PM, Morgan Arnold <morgan.arnold@proton.me> wrote:

> 
> 
> I asked around on the IRC channel a while ago about the status of ZFS support on Guix, and it was suggested that I ask here. I am aware of efforts made in the past to bring some rudimentary ZFS support to Guix (namely, https://issues.guix.gnu.org/45692, which appears to be quite dead), but was wondering if any new efforts have been considered. This is something which I would be very open to contributing to, as the lack of ZFS support is currently the only thing preventing me from using Guix as my main distro. It looks like there has is some general interest for better ZFS support on Guix, as evidenced by, say, https://issues.guix.gnu.org/73035.

Thank you for sharing those two issues; 45692 IIRC was the source/basis for the ZFS services in my private local channel that I've using for several years now.  I hadn't noticed 73035 yet, so I'll be looking at that soon.

There is also a couple of other issues that bring improvements related--at least tangentially-- to ZFS that are pending:

1) https://issues.guix.gnu.org/71482 which splits the ZFS userspace tools into a separate package and provides a helper function for creating a ZFS package for a specific kernel package.

2) https://issues.guix.gnu.org/55231 which adds support for including out-of-tree kernel modules in the initrd. This isn't strictly related to ZFS other than the documentation referencing ZFS in its example. The documentation patch had later been updated to include a different example of an out-of-tree module that is already packaged in Guix. I've also commented on it that I have essentially been using those patches for a number of years now.

> 
> Based on the response to 45692, I would also like to know if there is opposition to adding support for Guix, be it for philosophical or legal reasons. Assuming that no such opposition exists, 45692 seems to provide a very substantial chunk of the work which needs to be done for supporting ZFS on Guix, in particular automatic loading of the ZFS kernel module and automatic mounting of datasets. Ultimately, I would love to see support for `/' on ZFS, but based on discussions around 45692, it seems like this would be quite a bit more effort, although I must admit that I don't really understand why, other than that it involves modifying the behaviour of Shepherd earlier in the boot process. Other than examining the patches which were submitted for 45692, I assume that it would be worth looking more closely at how other filesystems are managed on Guix, although the treatment of ZFS probably necessarily differs, if just for the loading of the kernel module. As for` /' on ZFS, would a deep dive into the documentation for Shepherd be valuable in terms of understanding how to load the ZFS kernel module as early as possible? Alternatively, are there other modules in Guix that are sometimes loaded early (maybe GPU drivers? I know that they are loaded early sometimes) which might be worth examining to understand how to go about it?

I'd love to know where any opposition may be at as well. At this point I have a private channel which actually replaces much of the bootloader and initrd functionality (in part to support ZFS in the initrd using https://issues.guix.gnu.org/55231). In the past year, I actually took advantage of having basically replicated much of the initrd functionality in my channel to create a simple bootloader based on the Linux kernel (with the EFI stubloader) and a custom initrd that uses kexec to boot the actual system. It still needs a lot of polish, but has been good enough that combined with a few other small hacks and workarounds, I have several systems now booting with ZFS roots (some unencrypted, some using native encryption). I have done little to upstream most of it, or even to share what I've done, because of the seeming resistance to ZFS.

Cheers,
Kaelyn

> 
> Thanks,
> 
> Morgan