Re: ZFS on Guix

[raid5atemyhomework]

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