GNU bug report logs -
#45692
[PATCH 0/4] Even Better ZFS Support on Guix
Previous Next
Full log
Message #171 received at 45692 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 3 years and 120 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.