[bug#45692] [PATCH 0/3] Better Support for ZFS on Guix

[raid5atemyhomework via Guix-patches via <guix-patches@gnu.org>]

Good morning Liliana,

> Why is it necessary to define a
> file system as a service?

Because getting ZFS to work on Linux requires:

* That the ZFS module be added to the `initrd` so that Linux-libre can load it.
* That the ZFS module be actually *loaded*, because otherwise the system assumes it is loaded on some `udev` trigger.
* That the ZFS module is informed of when it should start scanning for ZFS pools in the system.
* That the above step happens before `user-processes` is started.

All that additonal complexity is conveniently packaged in the Guix service system, and you could have learned that if you had just bothered to actually read the patch.

+      (list ;; Install OpenZFS kernel module into kernel profile.
+            (service-extension linux-loadable-module-service-type
+                               zfs-loadable-modules)
+            ;; And load it.
+            (service-extension kernel-module-loader-service-type
+                               (const '("zfs")))
+            ;; Make sure ZFS pools and datasets are mounted at
+            ;; boot.
+            (service-extension shepherd-root-service-type
+                               zfs-shepherd-services)
+            ;; Make sure user-processes don't start until
+            ;; after ZFS does.
+            (service-extension user-processes-service-type
+                               zfs-user-processes)
+            ;; Install automated scrubbing and snapshotting.
+            (service-extension mcron-service-type
+                               zfs-mcron-jobs)
+
+            ;; Install ZFS management commands in the system
+            ;; profile.
+            (service-extension profile-service-type
+                               (compose list make-zfs-package))
+            ;; Install ZFS udev rules.
+            (service-extension udev-service-type
+                               (compose list make-zfs-package))))


> Why do we need to export a seemingly
> unrelated variable?

If you are referring to the `dependency->shepherd-service-name` variable, it is necessary in order to defer starting of ZFS pool scanning to after all `mapped-device` dependencies have been opened.

> Can this be tested? Is this sufficiently tested?

Yes, I have run VMs on each version I have ever sent.

> Are there any points Maxime that were drowned out by a huge wall of
> licensing-related messages being passed back and forth that I will not
> attempt to sift through in order to respond to this message? If so,
> have those been sufficiently addressed?

Other than grammar and wording of documentation / comments, and one point about using Guix-style Scheme instead of a bit of shell (even though there are probably more people who can properly review the latter than the former), Maxime had no other points.
Other reviewers had and those were already addressed.

>
> Another complicating factor for this bug in particular is that the mumi
> web interface and the raw messages are out of sync; I have no idea why
> that is the case, but trying to fetch a patch only to get one of your
> bump messages is not particularly encouraging.

Oh come on stop your shitty excuses.  Nobody would look at this unless I showed up at least once a week to pester Guix maintainers.  I already tried the wait-for-people-and-they-will-come.  Squeaky wheel gets the grease.  If you want contributors to be more respectful, then put up definitive responsibilities of who to contact for what and what to do if patches are being ignored.  Otherwise I am just going to talk smack at you, Prikler.

NO Thanks
raid5atemyhomework