Re: Status of ZFS support on Guix

[Kaelyn]

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