| Message ID | 6wemXB-PfHUqbuVr5-XRf0-tY4cKGGtKiUqrZPrIZYXoBw17L3xRuZrGOJQfTo5PKfFNCM8KyRTllidoc7asPE2x98BTiJSPVR7OSjxCuw8=@protonmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | Even Better ZFS Support on Guix | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/applying patch | fail | View Laminar job |
| cbaines/issue | success | View issue |
Hi raid5atemyhomework, Hi everyone, @raid5atemyhomework, thanks for all the patches! On Wed, 06 Jan 2021 15:57:19 +0000 raid5atemyhomework via Guix-patches via <guix-patches@gnu.org> wrote: > +@item @code{options} (default: @code{'()}) > +A list of string options to pass as options to the ZFS module. > +These will be put in a @file{/etc/modprobe.d/zfs.conf} file, > +for example setting this to @code{'("zfs_admin_snapshot=1" > +"zfs_trim_extent_bytes_min=0")} will create the following file: Sure, but it would be better to create a way to configure those module parameters in Guix in a declarative way, first. Your new kernel-loadable-module-service-type would be a good template to write a kernel-module-configuration-service that can be extended by other services. The latter should allow users to parametrize the kernel in general via the operating-system form, and also allow services to extend such configuration (with merging, and conflict detection). It would be used: (1) To declaratively specify the contents of something like /etc/modprobe.d . It shouldn't even be called "/etc/modprobe.d"--it should also be in the store instead. This directory is only useful for non-Linux-builtins. (2) If the "module" is built-in then the kernel command line must get the options instead. (in fact, it works as a kernel command line option also if it's a loadable module--so not sure we need /etc/modprobe.d at all--at least at first. But there's probably a maximal length for the kernel command line that we could exceed if we did that long term) I know it's annoying that Guix doesn't have this facility already, but the time to introduce an interface for /etc/modprobe.d and the kernel command line for builtin modules is before other services introduce their own ad hoc way to create /etc/modprobe.d--like this tries to do here. See also https://issues.guix.info/issue/42193 for an earlier attempt (which is already very far--but it has a bug somewhere). There's also already a kernel profile thing like you wrote in that patchset. (Note that I would prefer there not to be a "LOAD?" in there because it confuses loading the module (which is usually NOT started by user space but by the kernel on its own) and confguring the module (which has to be done by user space because it's specifying policy, not mechanism)) Also, because the kernel usually loads loadable modules on its own (potentially really early), /etc/modprobe.d has to be preset and known to the modprobe executable VERY EARLY (via environment variable MODPROBE_OPTIONS--see gnu/services.scm %modprobe-wrapper). It is totally possible that some modules in the initrd need options, too (see load-linux-modules-from-directory for where this would need to go). load-linux-module/fd already accepts options and flags--but both are not given on the call. For this, part of future kernel-module-configuration entries (the ones needed for modules in the initrd) should be copied into the initrd, too. Then there's the handoff between initrd and main system. It would be bad if the kernel tried and succeeded to load a module that is not in the initrd just before the modprobe.d directory is set up (because it would be loaded without passing the options the user configured)--so that needs to be avoided. @ludo: Could you help here? > +@example > +options zfs zfs_admin_snapshot=1 zfs_trim_extent_bytes_min=0 Note: This can be usefully put in a modprobe.d-like directory if zfs is a module, but not if it's built into the kernel. But it can be put into the kernel command line in both cases. But I guess the ZFS Linux kernel module can't be built-in into the kernel anyway. But that's a special case--in general, it's very much possible to make modules built-in. > + ;; You'd think we could've used kernel-module-loader-service-type, Definitely. > + ;; but the kernel-module-loader shepherd service is dependent on > + ;; file-systems, Yes--but why is that dependent on 'file-systems ? Is it because it needs /proc ? Or is it an oversight ? I would prefer to get rid of this dependency and then use kernel-module-loader-service-type. Also, this manual loading of kernel modules is not supposed to be the way to do things in Linux. That a kernel module was compiled as a module is an *implementation detail*--so Linux should (and usually does) automatically load kernel modules the first time a device for them is accessed (after all, how would user space know whether something is compiled as a module or built-in--that would be too much to ask). Linux is not a microkernel, so the kind of modularily modprobe.d suggests exists does not in fact exist in kernel space--even though Linux does a good job faking it: modprobe.d contains: * "alias": a feature to configure aliases, with wildcards (only one level of aliases allowed!) * "options" per module (also works for aliases with wildcards! That will be "fun" to map to Guix) * "install" in order to run some custom executable instead of loading the module. * "remove" in order to run some custom executable instead of unloading the module. * "blacklist" to ignore specific internal aliases of a module (that does not do what one would intuitively think!). If the file name of the regular file under /etc/modprobe.d is not used for anything, then we can just have one file /gnu/store/*modprobe.d/guix.conf in total in there. Then there are sysctl kernel parameters--but those Guix already exposes via sysctl-service-type. But those should also be made able to be extended by other services, and merge conflicts should be handled. For example, users often set net.ipv4.ip_forward=1 (for example via sysctl). Thank you for all your effort to make ZFS work nicely in Guix.
Hello Danny, > See also https://issues.guix.info/issue/42193 for an earlier attempt (which > is already very far--but it has a bug somewhere). There's also already a > kernel profile thing like you wrote in that patchset. > (Note that I would prefer there not to be a "LOAD?" in there because it > confuses loading the module (which is usually NOT started by user space > but by the kernel on its own) and confguring the module (which has to be > done by user space because it's specifying policy, not mechanism)) Looks like that patchset was merged in, so basically I can just depend on that? So the first patch in this patchset would be dropped? > But I guess the ZFS Linux kernel module can't be built-in into the kernel > anyway. > > But that's a special case--in general, it's very much possible to make modules > built-in. ZFS *can* be built-in to the kernel, Ubuntu does it. You can't distribute it like that (Ubuntu distributes it like that but presumably they have enough lawyers to muddy the waters so that they can get away with it), but as the documentation in this patch notes: the user has every right to do whatever they want on the machine they own, including build a Linux kernel that has ZFS built-in and run it, they just can't make that version available to somebody else. So to go whole-hog, we would have a service that replaces the kernel package and inserts kernel module sources in-tree somehow, then compiles Linux-libre on the user's machine. That would probably be a lot more painful to install ZFS with (the user has to recompile the whole kernel at each update of either kernel or ZFS, whereas with a kernel module the user has to recompile just the kernel module), so maybe kernel module is still better overall. > > - ;; You'd think we could've used kernel-module-loader-service-type, > > > > > > Definitely. > > > - ;; but the kernel-module-loader shepherd service is dependent on > > > > > > - ;; file-systems, > > > > > > Yes--but why is that dependent on 'file-systems ? Is it because it needs /proc ? > Or is it an oversight ? I would prefer to get rid of this dependency and then > use kernel-module-loader-service-type. Dunno --- one VM I tested, I removed the `zfs-scan-automount` shepherd service from the `file-systems` target, and the VM still wouldn't boot, claiming a stack overflow (the same error which I got when I was still trying to use kernel-module-loader-service-type here). Or maybe I just got confused with which VM was which, testing VMs wasn't a stress-free vacation. I just want ZFS, because MD RAID5 ate my homework, this is getting tiresome... One thing I notice about `kernel-module-loader-service-type` is that it's not instantiated in essential services, or indeed anywhere in Guix. A few services *do* extend it. But my **very rough** understanding is that if you're going to extend a service, it had better be instantiated *once* in the list of services. In particular I note that the documentation for `kernel-module-loader-service-type` shows an example where it uses `service` to program the `kernel-module-loader-service-type`, not `simple-service`. This suggests to me that `kernel-module-loader-service-type` is broken because it's not in the list of essential services but is extensible. Maybe. It's designed as an extensible service, but isn't instantiated at default. Maybe that's what really bit me and not the shepherd circular dependency loop? *shrug* > > Also, this manual loading of kernel modules is not supposed to be the way to > do things in Linux. That a kernel module was compiled as a module is > an implementation detail--so Linux should (and usually does) automatically > load kernel modules the first time a device for them is accessed (after all, > how would user space know whether something is compiled as a module or > built-in--that would be too much to ask). So how do I get ZFS loaded? Note that the devices it targets are block devices and it needs to scan for block devices that are formatted for ZFS. Do other filesystems have some autoload rule? Thanks raid5atemyhomework
Hi Danny, > > See also https://issues.guix.info/issue/42193 for an earlier attempt (which > > is already very far--but it has a bug somewhere). There's also already a > > kernel profile thing like you wrote in that patchset. > > (Note that I would prefer there not to be a "LOAD?" in there because it > > confuses loading the module (which is usually NOT started by user space > > but by the kernel on its own) and confguring the module (which has to be > > done by user space because it's specifying policy, not mechanism)) > > Looks like that patchset was merged in, so basically I can just depend on that? So the first patch in this patchset would be dropped? No, sorry, my mistake, only one patch completely unrelated to the actual new service type was merged in. In any case --- is this objection something that would block this patchset from being added to Guix? I appreciate that we should "do it right" --- but there's also an argument for "keep it simple", and the first patch in this patchset gets us a good part of the way to what is needed. It seems that my patch is equivalent to the existing WIP 2/6 `kernel-profile-service-type`, so maybe I can just steal that patch for now, write tests specific for it, and get on with running ZFS in production? Can we at least get patch 3/4 of *this* patchset merged since it's a trivial bugfix? How about patch 2/4, which is not so trivial, but does give some flexibility in case other filesystems want to be as ambitious as ZFS is? I imagine a later, much more comprehensive `kernel-module-configuration-service-type` can be built on top of `kernel-profile-service-type`, `kernel-module-loader-service-type`, and a later `kernel-module-options-service-type`. Then `zfs-service-type` can be modified to use that `kernel-module-configuration-service-type` instead of rolling its own bits and pieces. ---- On the other hand, if we want to think of `/` on ZFS, then we need a notion of kernel modules that are added to the `initrd` file, rather than to the `kernel` directory. Diving into `gnu/system/linux-initrd.scm`, I note that we can provide a kernel package and a list of modules to copy from the kernel package to the `initrd` by a `(flat-linux-module-directory linux modules)` function. I imagine that it would be possible to modify this as follows: * Have `flat-linux-module-directory` accept a list of packages from which to find module names, not just a single package. * Remove more code from `(operating-system-directory-base-entries os)`, and put the creation of the `"initrd"` file into a service, in much the same way that my patch does (unless there's an existing more-guixy way of putting files into `initrd`?). * Create a service type that gathers packages whose modules are to be added to the `initrd`, and if that list is non-empty, pass it to a new key `#:extra-linux-module-packages` of the `initrd` function. * `raw-initrd` would then pass that field together with the `linux` argument to the modified `flat-linux-module-directory` procedure. * Create another service type that gathers module names to be loaded at `boot` and appends them to the `#:linux-modules` to the `initrd` function. * Modify the `kernel-module-options-service-type` to pass in options via kernel command line always, maybe. Then ZFS module can get loaded early, at boot, before the switch from `initrd` root to the "real" root. * Create a service type that gathers additional pre-mount actions, which `raw-initrd` will accept as a new key `#:additional-pre-mount` and append to the `pre-mount` it passes to `boot-system`. * The `zfs-service-type` would then extend this service type to pass in an action to perform a `zpool import -a -N`, which makes ZFS scan for devices containing ZFS pools. * Somehow figure out a static build for the ZFS package, so we can use a statically-linked `zpool` in the above. * The `zfs-service-type` already inherits a ZFS package from the given `base-package`, I imagine it would be possible to make further inheritance which modifies the build to be static. It does require an additional build, though. Maybe an additional `root-on-zfs?` field in `zfs-configuration` can gate this, so that we don't add the static build and extend the boot script if `(not root-on-zfs?)` (i.e. use `kernel-module-configuration-service-type` if `(not root-on-zfs?)`, else use the new put-it-in-the-initrd service types). * Modify the various checks elsewhere so that ZFS poolnames can be passed as the `device` field of `file-system` records. See https://issues.guix.gnu.org/45643#3 * Then the installer can be modified so that if ZFS is included with the installer's profile, it can look at ZFS pools and offer to install to a ZFS pool instead of a `/dev` partition directly, then add `(file-system (device "rootpool") (mountpoint "/") (type "zfs"))` and the appropriate `zfs-service-type` and etc. and now we get `/` on ZFS. But that can come later, much much later, I just need ZFS, *any* ZFS, before RAID5 eats more of my homework. Thanks raid5atemyhomework > > But I guess the ZFS Linux kernel module can't be built-in into the kernel > > anyway. > > But that's a special case--in general, it's very much possible to make modules > > built-in. > > ZFScan be built-in to the kernel, Ubuntu does it. You can't distribute it like that (Ubuntu distributes it like that but presumably they have enough lawyers to muddy the waters so that they can get away with it), but as the documentation in this patch notes: the user has every right to do whatever they want on the machine they own, including build a Linux kernel that has ZFS built-in and run it, they just can't make that version available to somebody else. > > So to go whole-hog, we would have a service that replaces the kernel package and inserts kernel module sources in-tree somehow, then compiles Linux-libre on the user's machine. That would probably be a lot more painful to install ZFS with (the user has to recompile the whole kernel at each update of either kernel or ZFS, whereas with a kernel module the user has to recompile just the kernel module), so maybe kernel module is still better overall. > > > > - ;; You'd think we could've used kernel-module-loader-service-type, > > > > > > > > > > Definitely. > > > > > - ;; but the kernel-module-loader shepherd service is dependent on > > > > > > > > > - ;; file-systems, > > > > > > > > > > Yes--but why is that dependent on 'file-systems ? Is it because it needs /proc ? > > Or is it an oversight ? I would prefer to get rid of this dependency and then > > use kernel-module-loader-service-type. > > Dunno --- one VM I tested, I removed the`zfs-scan-automount` shepherd service from the `file-systems` target, and the VM still wouldn't boot, claiming a stack overflow (the same error which I got when I was still trying to use kernel-module-loader-service-type here). Or maybe I just got confused with which VM was which, testing VMs wasn't a stress-free vacation. I just want ZFS, because MD RAID5 ate my homework, this is getting tiresome... > > One thing I notice about `kernel-module-loader-service-type` is that it's not instantiated in essential services, or indeed anywhere in Guix. A few services do extend it. But my very rough understanding is that if you're going to extend a service, it had better be instantiated once in the list of services. > > In particular I note that the documentation for `kernel-module-loader-service-type` shows an example where it uses `service` to program the `kernel-module-loader-service-type`, not `simple-service`. This suggests to me that `kernel-module-loader-service-type` is broken because it's not in the list of essential services but is extensible. Maybe. It's designed as an extensible service, but isn't instantiated at default. Maybe that's what really bit me and not the shepherd circular dependency loop? shrug > > > Also, this manual loading of kernel modules is not supposed to be the way to > > do things in Linux. That a kernel module was compiled as a module is > > an implementation detail--so Linux should (and usually does) automatically > > load kernel modules the first time a device for them is accessed (after all, > > how would user space know whether something is compiled as a module or > > built-in--that would be too much to ask). > > So how do I get ZFS loaded? Note that the devices it targets are block devices and it needs to scan for block devices that are formatted for ZFS. Do other filesystems have some autoload rule? > > Thanks > raid5atemyhomework
diff --git a/doc/guix.texi b/doc/guix.texi index 78770151e3..62437083cb 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -13885,6 +13885,113 @@ a file system declaration such as: compress-force=zstd,space_cache=v2")) @end lisp +@node ZFS file system +@subsection ZFS file system + +The ZFS file system has a license incompatible with the Linux kernel, +and thus cannot be distributed with the kernel. However, as a user +you have the right to do whatever you want on your own hardware, +including download the ZFS source code, compile it, link it to your +own private copy of Linux, and run it. You can even use the Guix build +system to automate this. + +As a large and complex kernel module, ZFS on Linux has to be compiled +with a specific version of the kernel. Often even the latest ZFS +package available cannot be compiled with the latest Linux kernel +package provided by Guix System. Thus, installing the @code{zfs} +package is likely to fail. + +Instead, you have to use an older long-term-support Linux kernel. +Do not use @code{linux-libre-lts} as the latest long-term-support +kernel might be too new for the ZFS package; instead, explicitly +select the version number, like @code{linux-libre-5.4}. + +Then, you have to modify your system configuration file and use the +selected older kernel, and add the @code{zfs-service-type} service. + +@lisp +(use-modules (gnu)) +(use-package-modules + ; @dots{} + linux) +(use-service-modules + ; @dots{} + file-systems) + +(define my-kernel linux-libre-5.4) + +(operating-system + (kernel my-kernel) + ;; @dots{} + (services + (cons* (service zfs-service-type + (zfs-configuration + (kernel my-kernel))) + ; @dots{} + %desktop-services)) + ;; @dots{} + ) +@end lisp + +@defvr {Scheme Variable} zfs-service-type +This is the type of the service to compile and install OpenZFS to +your operating system. It loads the ZFS module at startup, imports +pools, mounts automounted ZFS datasets, installs the ZFS command +line tools, and can provide module options for the ZFS module. Its +value must be a @code{zfs-configuration} record (see below). + +Here is an example use: + +@lisp +(service zfs-service-type + (zfs-configuration + (kernel linux-libre-5.4) + (options '("zfs_arc_max=5000000000")))) +@end lisp +@end defvr + +@deftp {Data Type} zfs-configuration +This data type represents the configuration of the ZFS service. +The available fields are: + +@table @asis +@item @code{kernel} +The package of the Linux kernel to compile ZFS for. Required. + +@item @code{base-zfs} (default: @code{zfs}) +The ZFS package to use. It will be modified to use the indicated +kernel. + +@item @code{options} (default: @code{'()}) +A list of string options to pass as options to the ZFS module. +These will be put in a @file{/etc/modprobe.d/zfs.conf} file, +for example setting this to @code{'("zfs_admin_snapshot=1" +"zfs_trim_extent_bytes_min=0")} will create the following file: + +@example +options zfs zfs_admin_snapshot=1 zfs_trim_extent_bytes_min=0 +@end example +@end table +@end deftp + +Once your system has been configured to include the ZFS service +and you have restarted the system, you can manage ZFS pools and +datasets with @code{zpool} and @code{zfs} commands. + +ZFS datasets with an appropriate @code{mountpoint} property will +be automounted at startup after the root file system is started. +Encrypted datasets that are automounted will cause boot to pause +and prompt for the password to be provided on the console. + +It's possible to have a ZFS dataset as your @code{/home} by simply +setting the @code{mountpoint} property. However, note that ZFS will +refuse to mount over a non-empty directory, so if your root +filesystem already has a non-empty @code{/home}, you should remove +it and its contents, then restart the system. + +Having ZFS as a root filesystem or as @code{/boot} is not supported +yet. + @node Mapped Devices @section Mapped Devices diff --git a/gnu/local.mk b/gnu/local.mk index 53a67e6ffe..49073ac2ac 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -39,6 +39,7 @@ # Copyright © 2020 Martin Becze <mjbecze@riseup.net> # Copyright © 2020 Malte Frank Gerdes <mate.f.gerdes@gmail.com> # Copyright © 2020 Vinicius Monego <monego@posteo.net> +# Copyright © 2021 raid5atemyhomework <raid5atemyhomework@protonmail.com> # # This file is part of GNU Guix. # @@ -601,6 +602,7 @@ GNU_SYSTEM_MODULES = \ %D%/services/dict.scm \ %D%/services/dns.scm \ %D%/services/docker.scm \ + %D%/services/file-systems.scm \ %D%/services/authentication.scm \ %D%/services/games.scm \ %D%/services/ganeti.scm \ diff --git a/gnu/services/file-systems.scm b/gnu/services/file-systems.scm new file mode 100644 index 0000000000..7a92a2b9d5 --- /dev/null +++ b/gnu/services/file-systems.scm @@ -0,0 +1,136 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2021 raid5atemyhomework <raid5atemyhomework@protonmail.com> +;;; +;;; This file is part of GNU Guix. +;;; +;;; GNU Guix is free software; you can redistribute it and/or modify it +;;; under the terms of the GNU General Public License as published by +;;; the Free Software Foundation; either version 3 of the License, or (at +;;; your option) any later version. +;;; +;;; GNU Guix is distributed in the hope that it will be useful, but +;;; WITHOUT ANY WARRANTY; without even the implied warranty of +;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;;; GNU General Public License for more details. +;;; +;;; You should have received a copy of the GNU General Public License +;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>. + +(define-module (gnu services file-systems) + #:use-module (gnu packages file-systems) + #:use-module (gnu services) + #:use-module (gnu services base) + #:use-module (gnu services shepherd) + #:use-module (guix gexp) + #:use-module (guix packages) + #:use-module (guix records) + #:export (zfs-service-type + zfs-configuration + zfs-configuration?)) + +(define-record-type* <zfs-configuration> + zfs-configuration make-zfs-configuration zfs-configuration? + ; kernel you want to compile the base-zfs module for. + (kernel zfs-configuration-kernel) + ; base package that will be compiled for the kernel + (base-zfs zfs-configuration-base-zfs (default zfs)) + ; list of string options. + (options zfs-configuration-options (default '()))) + +(define (make-zfs-package conf) + (let ((base-zfs (zfs-configuration-base-zfs conf)) + (kernel (zfs-configuration-kernel conf))) + (package + (inherit base-zfs) + (name (string-join (list (package-name base-zfs) + "for" + (package-name kernel) + (package-version kernel) + "version") + "-")) + (arguments (cons* #:linux kernel (package-arguments base-zfs)))))) + +(define (zfs-loadable-module conf) + (list (list (make-zfs-package conf) "module"))) + +(define (zfs-shepherd-services conf) + (let* ((zfs-package (make-zfs-package conf)) + (zpool (file-append zfs-package "/sbin/zpool"))) + (list + (shepherd-service + (documentation "Scans for ZFS pools and automounts filesystems.") + (provision '(zfs-scan-automount)) + (requirement '(root-file-system)) + (modules `((srfi srfi-1) + (srfi srfi-34) + (srfi srfi-35) + (rnrs io ports) + ,@%default-modules)) + (start #~(lambda _ + (and + ;; You'd think we could've used kernel-module-loader-service-type, + ;; but the kernel-module-loader shepherd service is dependent on + ;; file-systems, and file-systems is made dependent on this + ;; service. And we need the kernel module to be loaded before we + ;; scan for ZFS pools. So break the dependency loop by just + ;; loading ZFS module here by ourselves. + (or (file-exists? "/proc/sys/kernel/modprobe") + (begin + (format (current-error-port) "error loading 'zfs' module: ~a~%" + "Kernel is missing loadable module support.") + #f)) + (guard (c ((message-condition? c) + (format (current-error-port) + "error loading 'zfs' module: ~a~%" + (condition-message c)) + #f)) + (let ((modprobe (call-with-input-file "/proc/sys/kernel/modprobe" + get-line))) + (invoke/quiet modprobe "--" "zfs"))) + + ; scan for pools and automount contained datasets. + (guard (c ((message-condition? c) + (format (current-error-port) + "error importing zpools: ~a~%" + (condition-message?)) + #f)) + ;; (current-output-port) is typically connected to /dev/klog, + ;; so redirect it to (current-error-port) so that user can see + ;; prompts for passphrases on console + (with-output-to-port (current-error-port) + (lambda () + (invoke #$zpool "import" "-a" "-l"))))))) + (stop #~(const #t)))))) + +(define (zfs-profile-service conf) + (list (make-zfs-package conf))) + +(define (zfs-etc-service conf) + (let ((options (zfs-configuration-options conf))) + (if (null? options) + '() + `(("modprobe.d/zfs.conf" + ,(plain-file "zfs.conf" + (string-join (cons "options zfs" options) " "))))))) + +(define zfs-service-type + (service-type (name 'zfs) + (extensions + (list + ; install the kernel module + (service-extension kernel-loadable-module-service-type + zfs-loadable-module) + ; load ZFS module, scan ZFS pools, and automount filesystems + (service-extension shepherd-root-service-type + zfs-shepherd-services) + ; make sure automount occurs before file-systems target is reached + (service-extension file-systems-target-service-type + (const '(zfs-scan-automount))) + ; install ZFS management tools + (service-extension profile-service-type + zfs-profile-service) + ; install ZFS module options + (service-extension etc-service-type + zfs-etc-service))) + (description + "Install ZFS, an advanced filesystem and volume manager.")))
From deded39fe88c44a18b0b66bab8c4300aca4c387e Mon Sep 17 00:00:00 2001 From: raid5atemyhomework <raid5atemyhomework@protonmail.com> Date: Wed, 6 Jan 2021 09:24:20 +0800 Subject: [PATCH 4/4] gnu: Add ZFS service. * gnu/services/file-systems.scm: New file. (zfs-service-type): New variable. (zfs-configuration): New variable. (zfs-configuration?): New procedure. * gnu/local.mk: Add gnu/services/file-systems.scm. * doc/guix.texi (ZFS file system): New subsection. --- doc/guix.texi | 107 ++++++++++++++++++++++++++ gnu/local.mk | 2 + gnu/services/file-systems.scm | 136 ++++++++++++++++++++++++++++++++++ 3 files changed, 245 insertions(+) create mode 100644 gnu/services/file-systems.scm -- 2.29.2