Subject: [bug#45692] [PATCH v4 3/3] gnu: Add ZFS service type.

From: raid5atemyhomework <[email-masked]>
Date: Mon, 06 Sep 2021 10:52:45 +0000

Hello Xinglu Chen,

Thank you for your interest.

> You might want to bring up the topic of subsystem maintainers on the
> guix-devel mailing list to get some more attention.

Not personally interested.

> > +The above will keep 8 @code{frequent} snapshots and 12 @code{hourly} snapshots.
> > +@code{daily}, @code{weekly}, and @code{monthly} snapshots will keep their
> > +defaults (31 @code{daily}, 8 @code{weekly}, and 12 @code{monthly}).
> > +
> > +@end table
> > +@end deftp
>
> IIUC, there is not way specify ZFS pools in the ‘file-systems’ field of
> an <operating-system> record. Does this mean that ZFS as the root file
> system is not supported, and if so, is there a particular reason for
> this?

No, and as you saw, that requires some more work.

In particular, older versions of this patchset included the ability to add ZFS pools / datasets `file-system` objects, but the exact implementation was objected to, with no suggestion for what alternative to use instead.  Since I thought it was contentious, I removed it entirely instead.

Note that ZFS-on-Root on Guix is even harder because of the need to put loading in `initrd`, and a lot of coding as well, not just `file-system`s support.

Given the sheer lack of review and etc etc, I am not encouraged to write more code that will remain unreviewed and unmerged.  Maybe if this gets merged as-is, I will, but otherwise, I don't see the point.

> The field name usually just contains the package name, so ‘zfs’ and
> ‘zfs-auto-snapshot’ instead of ‘base-zfs’ and ‘base-zfs-auto-snapshot’.

The point is that the service does **NOT** use `base-zfs` directly --- it creates a new version of that package, targeted towards the specific kernel you provided.  This is necessary since internal kernel APIs and ABIs may change between versions, even minor v==ersions (Linux has no commitment to keeping kernel interfaces stable, it only has a commitment to keeping userspace interfaces stable, and OpenZFS **requires** the kernel interfaces, so it is safest to compile specifically to the kernel version that is used).

Thus the ***`base-`*** prefixes: the `zfs-service-type` does not use the `base-zfs` and `base-zfs-autosnapshot` packages as-is, they are instead used as the basis for the actual packages that are compiled and installed into the system.  I thought this would be sufficiently different from other services, which use package names as-is (but use the packages as-is, without inheriting from them, unlike this service) that the `base-` prefix was justified.

> > -                       ;; Output to current-error-port, otherwise the
> >
> >
> > -                       ;; user will not see any prompts for passwords
> >
> >
> > -                       ;; of encrypted datasets.
> >
> >
> > -                       ;; XXX Maybe better to explicitly open /dev/console ?
> >
> >
>
> Seeing this comment, I assume that encrypted pools are supported, right?

Encrypted datasets are supported, yes.  If you set `keylocation=prompt` then the `init` process will pause and ask for the password on the console.  You can even use `keylocation=file:///some/keyfile`, I also tested that in a VM.  My own production setup (which doesn't use this service, but includes some code copy-pasted from this service) uses `keylocation=file:///*elided*`.

> > -        '(frequent hourly daily weekly monthly))))
> >
> >
>
> Maybe use something like
>
> (map first %default-auto-snapshot-keep)
>
> to avoid having to changing it if things change in the future.

Good idea, thank you.

Thanks
raid5atemyhomework