Hi guix-developers, I just found out that ZFS on Linux maintains a file `/etc/zfs/zpool.cache` which contains information on ZPOOLs (i.e. ZFS-managed RAID arrays). I just didn't encounter this file before on Guix because the file is created if and only if the directory `/etc/zfs/` exists, and that directory is not created by the ZFS installation process on Guix (because I'm the one making the ZFS installation process on Guix right now and I didn't know about this directory).
Now, my understanding is that `/etc/` directory is recreated at each `guix system reconfigure`. Thus, if ZFS maintains information in `/etc/zfs/` then on a reconfigure the information is lost. If so --- for Guix, what should I use instead? As it happens, ZFS uses this directory for at least these things: * `/etc/zfs/zpool.cache` - a binary file containing information about what ZPOOLs were created on this system. The `zpool` command updates this file! * `/etc/zfs/zpool.d/` - a directory of scripts that can be used to extend the `zpool` command; the ZFS release normally installs a bunch of files it has in those directories. * `/etc/zfs/vdev_id.conf` - a sysad-managed configuration file that is used to indicate the paths. * `/etc/zfs/zed.d/` - a directory of scripts that are executed when particular events are detected by the ZFS Event Daemon (which I didn't know about, and which should also be installed and started as a Shepherd service as well). Sysads are supposed to link or copy files from `/libexec/zfs/zed.d/` (which are provided by the installation) to enable/disable particular zedlets, and can add other events here. The ZFS release normally links some of the files in `/libexec/zfs/zed.d/`. * `/etc/zfs/zfs-functions` - a shell file containing functions that some bits of ZFS `init` scripts / `initramfs` scripts use, and maybe more. I think Guix can safely ignore this, though somebody (most likely me) will have to read it through to understand how ZFS actually implements some of its magical abilities. Of these, many are stuff that we might plausibly generate by adding more fields in `zfs-configuration`, though the ZED and its zedlet system would bring in the possibility of writing Guile GEXP to create scripts for particular events. However, I'm not so sure about `zpool.cache` file. For one, it doesn't contain text data so it's not easy to generate it ourselves. On the other hand I've got ZFS working without it, by just using `zpool import -a` to have ZFS scan for all devices. The problem with this technique is if Guix is used on a system with several dozen or hundred devices in various ZPOOLs; this would slow down boot while ZFS is checking all arrays and figuring out which device goes into which array, whereas a `zpool.cache` file would let ZFS know about all pools created or imported on the system and would not need to scan their labels and reassemble their arrays and so on. Another is that for a complex enough setup, a storage device might be connected to the hardware by hostile parties (for example, by network-addressable block devices, or USB) that contains a ZPOOL with a `mountpoint=/gnu/store` (or other sensitive directory) property, which, if auto-imported via `zpool import -a`, could let particular subdirectories of the filesystem to be subverted. How best do I handle this? Thanks raid5atemyhomework
