all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* ZFS on Guix, again
@ 2021-02-20  8:48 raid5atemyhomework
  2021-02-20 11:44 ` 宋文武
  2021-02-22  8:57 ` Ludovic Courtès
  0 siblings, 2 replies; 6+ messages in thread
From: raid5atemyhomework @ 2021-02-20  8:48 UTC (permalink / raw)
  To: guix-devel@gnu.org, Ludovic Courtès


Hi guix-devel,

I had some questions on the big ZFS guix bugpatches a week ago, and did not find any response, so I am back here pestering everyone.

Anyway:

* I am wary of calling the service type that accepts kernel modules as `linux-loadable-module-service-type`:
  * The equivalent existing `operating-system` field is `kernel-loadable-modules`.  Because `operating-system` is user-facing, we cannot rename it to `linux-loadable-modules`, thus leading to a naming inconsistency (the `operating-system` field is `kernel-loadable-modules`, the service type that adds items to that field is `linux-loadable-module-service-type`).
  * Just because Guix only supports two kernels *now* and only one of them (`linux-libre`) supports loadable modules does not mean in the future Guix will not support *other* kernels with a concept of a loadable module (e.g. FreeBSD kernel).  So it seems premature to only name it `linux` loadable modules when the concept of a kernel-loadable module apparently also exists in other kernels (since OpenZFS itself can be compiled as an out-of-tree kernel module for FreeBSD, and there is nothing really preventing Guix from supporting FreeBSD in the future).
  * There is already an existing `kernel-module-loader-service-type`.  This is used to explicitly load kernel modules, which either have to be in the `kernel-loadable-modules` field of `operating-system`, or provided by extending with the new, inconsistently named `linux-loadable-module-service-type`.

Changing the name to `linux-loadable-module-service-type` means:

* We should deprecate `kernel-module-loader-service-type` and replace it with an equivalent `linux-module-loader-service-type`.
* We should deprecate the `operating-system` `kernel-loadable-modules` field and replace it with an equivalent `linux-loadable-modules` field.

In any case, I have some sketches below.

I want to create two new service types:

* `linux-profile-builder-service-type` which has configuration `linux-profile-builder-configuration`.
  * `linux-profile-builder-configuration` has fields:
    * `linux-libre` which is the `kernel` field of the `operating-system`.
    * `loadable-modules` which is the `kernel-loadable-modules` field of the `operating-system`.
  * This type is extensible.  `compose` is `identity`, `extend` is `(lambda (config extensions) ((apply compose identity extensions) config))`
    * In short, extensions of this service-type should return a procedure which takes the `linux-profile-builder-configuration` and modifies it.
  * This extend the root `system-service-type`, creating the `kernel` output.
* `linux-loadable-module-service-type`, which takes as configuration an empty list.
  * This type is extensible.  `compose` is `concatenate`, `extend` is `append`.
  * This has a single service extension:
    * Extends `linux-profile-builder-service-type` and if the configuration is not an empty list, extends the Linux-libre profile builder by a procedure that appends the list of kernel-loadable modules.

The above gives a separation of concepts:

* The `linux-profile-builder` builds the kernel profile for Linux-libre systems.
* The `linux-loadable-module-service-type` ensures that the kernel profile contains particular loadable kernel modules.

In the future there may be additional non-module things we can add to the Linux profile, so I think this separation is useful.

--

Another point I want to bring up is the use of `file-system-service-type`.

If we use `file-system-service-type` to extends the `file-systems` Shepherd service, then we need to add some kind of field to exempt the ZFS service from being added to `/etc/fstab`.

Note that ZFS expects there to be dozens of filesystems, and that creating and destroying file systems is just a "simple" `zfs create pool/file/system` command.  Each possible use or application may need to have specific tuning, thus each application may very well have its own file system with its own ZFS parameters specifically tuned for that application.

This is not a good fit with the `operating-system` mechanism in Guix, where you have to reconfigure the entire system just to add or remove file systems.

Nevertheless the ZFS still supports manual filesystem management, you just need to specify the `legacy` parameter, so it's still possible to use `operating-system` and its `file-systems` field to manage ZFS mounts, you just need to do `zfs create -o mountpoint=legacy pool/file/system`.  Though Guix still needs some modifications since the `device` would have to be `"pool/file/system"` and some parts of Guix attempt to search for a block device.

However, for the case where the user expects the "typical" ZFS style of managing file systems, we need to mount all the ZFS file systems and ensure that they aer all already mounted by the time `file-systems` Shepherd service is started.  This means we need to be able to extend the `requirement` of the `file-systems` Shepherd service.  And we need to do that without putting any extra `/etc/fstab` entries since for "typical" ZFS style of managing file systems, they are required to ***not*** be put in `/etc/fstab`.

* We can just create a separate `file-systems-target-service-type` that always accepts (list of) symbols that the `file-systems` Shepherd service will `requirement`.  Then `file-systems-service-type` can just extend that service type.  This is what I already originally did.
* 宋文武 proposed to instead make `file-systems-service-type` accept a heteregonous list of either symbols or `<file-system>` records.
  * Ludo' ***agreed*** with this.... but then says that mixing symbols and `<file-system>` records in the same list is bad design.  So... this is confusing.

There are two alternatives:

* Go with what I already proposed which I think is more general-purpose and cleaner (there is a separate service type that accepts symbols, and a separate service type that accepts `<file-system>` records, and the latter just extends the former).
* Don't make a separate service type, but now we need to add some kind of `fstab?` field to `file-system` so that the ZFS shepherd service that mounts ZFS file systems will not be included in the `/etc/fstab`.

I think overall that having lots of tiny service types that are then combined together fits the functional design of Guix better.  So I would strongly propose my original design rather than hacks on top of `file-system-service-type`.

Thanks
raid5atemyhomework


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-03-09  2:34 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-20  8:48 ZFS on Guix, again raid5atemyhomework
2021-02-20 11:44 ` 宋文武
2021-02-22  8:57 ` Ludovic Courtès
2021-02-23  1:11   ` raid5atemyhomework
2021-02-25  5:08     ` raid5atemyhomework
2021-03-09  2:34       ` raid5atemyhomework

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.