From owner-freebsd-geom@freebsd.org Fri Nov 16 22:35:40 2018 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FEF11106904 for ; Fri, 16 Nov 2018 22:35:40 +0000 (UTC) (envelope-from coco@executive-computing.de) Received: from mail.moehre.org (mail.moehre.org [195.96.35.7]) by mx1.freebsd.org (Postfix) with ESMTP id 739736C876 for ; Fri, 16 Nov 2018 22:35:39 +0000 (UTC) (envelope-from coco@executive-computing.de) Received: from mail.moehre.org (unknown [195.96.35.7]) by mail.moehre.org (Postfix) with ESMTP id 4F46F38D23 for ; Fri, 16 Nov 2018 23:18:03 +0100 (CET) X-Spam-Flag: NO X-Spam-Score: -100.918 X-Spam-Level: X-Spam-Status: No, score=-100.918 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, AWL=-0.072, TW_GP=0.077, TW_ZF=0.077, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mail.moehre.org ([195.96.35.7]) by mail.moehre.org (mail.moehre.org [195.96.35.7]) (amavisd-new, port 10024) with ESMTP id G_iBr2qK4yBL for ; Fri, 16 Nov 2018 23:18:03 +0100 (CET) Received: from bsdbuch.c0c0.intra (p54BEC3DB.dip0.t-ipconnect.de [84.190.195.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: coco@executive-computing.de) by mail.moehre.org (Postfix) with ESMTPSA id E2ACD38D1C for ; Fri, 16 Nov 2018 23:18:02 +0100 (CET) Date: Fri, 16 Nov 2018 23:18:09 +0100 From: Marco Steinbach To: freebsd-geom@freebsd.org Subject: eli encrypted providers for zfs raidz1 Message-ID: <20181116231809.40a8f74c@bsdbuch.c0c0.intra> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.2) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 739736C876 X-Spamd-Result: default: False [-3.04 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[mail.moehre.org]; NEURAL_HAM_SHORT(-0.92)[-0.916,0]; RCVD_NO_TLS_LAST(0.10)[]; RECEIVED_SPAMHAUS_PBL(0.00)[219.195.190.84.zen.spamhaus.org : 127.0.0.10]; R_DKIM_NA(0.00)[]; IP_SCORE(-0.00)[country: DE(-0.01)]; ASN(0.00)[asn:8354, ipnet:195.96.32.0/19, country:DE]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.960,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.95)[-0.951,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-geom@freebsd.org]; DMARC_NA(0.00)[executive-computing.de]; RCPT_COUNT_ONE(0.00)[1] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 22:35:40 -0000 Hi. I'm using 11.2-RELEASE r335510 amd64 GENERIC in an Oracle VirtualBox setup on FreeBSD, which is what comes out of the box, when installing 11.2 from the distribution media. I'm trying to wrap my head around on how to avoid a zpool resilver on a non-booting ZFS raidz1 of off four equally sized (GPT) partitions on four distinct drives using eli for encyption. IOW: I do struggle with finding a way to attach all the providers such, that ZFS does not initiate a resilver due to the providers being attached sequentially. I've created and initialized the partitions as follows (generic notation, comments on chosen encryption algo welome, since this testing setup lacks AES-NI): # gpart create -s gpt /dev/ada[2-5] # gpart add -t freebsd-zfs /dev/ada[2-5] # geli init -e AES-CBC -l 128 /dev/ada[2-5]p1 Then I attached the geli partitions like so: # geli attach /dev/ada[2-5]p1 And finally created a raidz1 spanning all four partitions: # zpool create u0001 raidz1 /dev/ada[2-5]p1.eli That works flawlessly. And naturally, after a reboot none of the encrypted devices is available to the zpool then, unless I attach them. Doing so using geli attach requires me to attach them sequentially, which then results in ZFS resilvering the pool. So, here's my questions: 1. Is the inavoidable resilver intended behaviour based on current implementation, or am I missing something ? 2. In case I use a bootable zfsroot (cudos to allanjude@, I highly recommend his BSDCan presentations on the matter), is there a way to hand over the zfsroot passphrase to eli for automatically attaching other providers ? Please note, that I'd like to stick as close as possible to what the base system offers for this use-case. MfG CoCo