From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 0A6OOIHy+V9nNgAA0tVLHw (envelope-from ) for ; Sat, 09 Jan 2021 18:14:25 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id RBY9NIHy+V97XAAAbx9fmQ (envelope-from ) for ; Sat, 09 Jan 2021 18:14:25 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id A083C9402C8 for ; Sat, 9 Jan 2021 18:14:25 +0000 (UTC) Received: from localhost ([::1]:34720 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kyIkq-00059Z-LS for larch@yhetil.org; Sat, 09 Jan 2021 13:14:24 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50114) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kyIki-00059G-Bw for guix-devel@gnu.org; Sat, 09 Jan 2021 13:14:16 -0500 Received: from mail-40135.protonmail.ch ([185.70.40.135]:22492) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kyIkf-0003Ab-Bs for guix-devel@gnu.org; Sat, 09 Jan 2021 13:14:15 -0500 Date: Sat, 09 Jan 2021 18:14:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1610216050; bh=WYGu3sOfVCLEV7yBfQLkFm++2pHuaUQpTGwRofXoDr8=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=Ju45GEdKLaQZFG0gnnVHt01MoNm1Lt1iX0GlekT8V1QtYp4qB02Yhn5NuRoqcRVEK t1IHaYwJCPIbTkrAvYyQ1XfouE8I968+Byv0cvw/T8Is25z6P7dRrWw0ldxZeeaSFZ txnDZgZmg789qEP4KsGFa4lQpr0Fe5vpFcitoe/8= To: "guix-devel@gnu.org" From: raid5atemyhomework Subject: Re: ZFS on Guix Message-ID: <07kwAFNpjhGFe7ArkjjAtRhr564wvMPGhHFyjGb_XdmmPNddKTmT9Swky1NbbUxHBC4xw3p-m_3JyW16Ql9J7PLyk6UdhCsA2cdkHehdti8=@protonmail.com> In-Reply-To: References: <_1CLe9QSGsoMlu5WxBMXm4CbFLM_M9iRG1XQF9GDsK0GP208jpngdymfix4tAfoLP94mhMTt-Tx6OP2xN_n78Jhx5KQzkiqPpIci_44C9OI=@protonmail.com> <87lfd698xq.fsf@zancanaro.id.au> <5DEAAAD8-1D08-4489-9AEC-675618F8E388@zancanaro.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.135; envelope-from=raid5atemyhomework@protonmail.com; helo=mail-40135.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: raid5atemyhomework Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -3.05 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail header.b=Ju45GEdK; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: A083C9402C8 X-Spam-Score: -3.05 X-Migadu-Scanner: scn0.migadu.com X-TUID: VR3pMia391l2 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 jus= t 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 cre= ated by the ZFS installation process on Guix (because I'm the one making th= e ZFS installation process on Guix right now and I didn't know about this d= irectory). Now, my understanding is that `/etc/` directory is recreated at each `guix = system reconfigure`. Thus, if ZFS maintains information in `/etc/zfs/` the= n 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 t= he `zpool` command; the ZFS release normally installs a bunch of files it h= as 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 particu= lar 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 we= ll). Sysads are supposed to link or copy files from `/libexec/zfs/zed.d/` = (which are provided by the installation) to enable/disable particular zedle= ts, and can add other events here. The ZFS release normally links some of t= he files in `/libexec/zfs/zed.d/`. * `/etc/zfs/zfs-functions` - a shell file containing functions that some bi= ts 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 magi= cal abilities. Of these, many are stuff that we might plausibly generate by adding more fi= elds in `zfs-configuration`, though the ZED and its zedlet system would bri= ng in the possibility of writing Guile GEXP to create scripts for particula= r events. However, I'm not so sure about `zpool.cache` file. For one, it doesn't con= tain 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 imp= ort -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 var= ious 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` f= ile would let ZFS know about all pools created or imported on the system an= d 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 co= nnected to the hardware by hostile parties (for example, by network-address= able block devices, or USB) that contains a ZPOOL with a `mountpoint=3D/gnu= /store` (or other sensitive directory) property, which, if auto-imported vi= a `zpool import -a`, could let particular subdirectories of the filesystem = to be subverted. How best do I handle this? Thanks raid5atemyhomework