Re: ZFS on Guix, again

[raid5atemyhomework <raid5atemyhomework@protonmail.com>]

Hi Ludo,

> > I agree with 宋文武 regarding ‘file-system-service-type’.
> > raid5atemyhomework raid5atemyhomework@protonmail.com skribis:
> >
> > > 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`.
> >
> > Looks like this fstab issue is the main reason why you felt the need to
> > define an extra service type. Why is it important that ZFS not be
> > listed in /etc/fstab?
>
> Because on all non-Guix operating systems, they aren't listed in`/etc/fstab`:
>
> -   https://docs.oracle.com/cd/E19120-01/open.solaris/817-2271/gaztn/index.html


So what do we do here?

* Force all ZFS filesystems to be declared `mountpoint=legacy` and be written as `file-system` declarations in the `operating-system` (which will eventually reach `/etc/fstab`).
  * This is undesirable since ZFS users expect that setting up mount points for ZPOOL and ZFS datasets are just handled by the same commands that create the ZPOOL and ZFS dataset.  This is in contrast with other file systems where the creation of the filesystem is a separate step from adding its mount point.
  * If a ZFS filesystem is created or destroyed (for example I might want to create a temporary filesystem to `zfs send` to in order to implement defragmentation, or to recompress data if I forgot to set `compression=on`) then the user has to edit the configuration file and then  `guix system reconfigure` in order to make the changes stick.  Most ZFS users just create and destroy ZFS datasets as part of maintenance.
  * If Guix goes this way, most ZFS users (including me) will not consider ZFS support on Guix to be anywhere near "serviceable".
* Hack a `fstab?` field in `file-system` forms.
  * Arguably bad design.
* Just split up the Shepherd service into a `file-systems-target-service-type` and have `file-systems-service-type` extend it, like I already proposed before.

---

Also how about `linux-loadable-modules-service-type`? Is the proposed design okay?  Do we really want to name it `linux-loadable-modules-service-type` in contrast to the current `operating-system` field `kernel-loadable-modules`?

Thanks
raid5atemyhomework

Thanks
raid5atemyhomework