GNU bug report logs - #45692
[PATCH 0/4] Even Better ZFS Support on Guix

Previous Next

Full log

View this message in rfc822 format

From: raid5atemyhomework <raid5atemyhomework <at> protonmail.com>
To: "45692 <at> debbugs.gnu.org" <45692 <at> debbugs.gnu.org>
Subject: [bug#45692] [PATCH v3 0/3] New patch series for Even Better ZFS Support on Guix
Date: Mon, 22 Mar 2021 14:33:01 +0000

This is a new patch series, please completely forget the previous patch series.

Notable differences are:

* ZFS automounted datasets are mounted before `user-processes` instead of `file-systems`, since there is strong objection to modifying `file-systems` so it can be extended to allow ZFS automounted datasets to be mounted before `file-systems`.  This prevents easy `/home` on ZFS (though see the added documentation in 3/3 for a workaround).
* The old `kernel-loadable-module-service-type` is renamed to `linux-loadable-module-service-type`, despite the corresponding `operating-system` field being named `kernel-loadable-modules`, and the loader service type being named `kernel-module-loader-service-type` :rolleyes:.
* There is a new `linux-builder-service-type`, which can be extended with a function to modify its `linux-builder-configuration`.  The `linux-loadable-module-service-type` extends this base service.  I think this design patttern should be more extensively used in Guix; currently services are only extensible via one field of their configuration, this pattern allows creating multiple service types for each extensible field of the configuration.  In this particular case, the `kernel` of the `linux-builder-service-type` can be extended (by adding/removing `configure` or `make` flags, or added `inputs`) independently of the list of loadable modules using this design pattern.
* Auto-scrub and auto-snapshot is now supported, with additional fields in `zfs-configuration` to support it.
* The auto-mounting Shepherd service has been renamed `zfs-auto-mount` (previously `zfs-automount`).
* Documentation includes a list of things that are currently not (fully) supported.

Personally I'm not particularly motivated to push this anymore.  I have a frankenstein's `configuration.scm` that gets me the bits of ZFS functionality that I absolutely need, with the rest something I'm just living without, and while it would be *nice* to have *some* out-of-the-box support for ZFS (or at least make it easy to get a box to get support for ZFS out of), I personally don't need it at this point.

Patch 1/3 corresponds to the original Patch 1/4.  Patch 2/3 has no corresponding patch in the original patch set, but is the same patch as https://issues.guix.gnu.org/47134 which nobody is looking at, as usual.  Patch 3/3 corresponds to the original Patch 4/4.

The original Patch 2/4 has been removed since it's what makes `/home` on ZFS work by making `file-systems` extensible.  The original Patch 3/4 was already merged.

This patch series is minimally tested compared to the previous patch series; I have homework to store on my ZFS pool and should really stop fooling around with the operating system.  I have this patch series running in a VM with a ZFS pool.  Auto-scrub is not tested, though auto-snapshot looks working.  Auto-mounting works as with previous patch series.  Encrypted and compressed filesystems are untested but I don't expect it to be significantly regressed compared to the previous patch series.

More work can be done for ZFS support.  But I think the current set gives a workable ZFS support; further work can be done piecemeal afterwards.  The documentation includes notes for anyone who feels motivated enough to keep improving the ZFS support.

Thanks
raid5atemyhomework

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.