From owner-svn-src-head@FreeBSD.ORG Sun Jan 18 23:25:30 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9718DC0 for ; Sun, 18 Jan 2015 23:25:30 +0000 (UTC) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C962DBB for ; Sun, 18 Jan 2015 23:25:29 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id k14so28961130wgh.1 for ; Sun, 18 Jan 2015 15:25:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yaWxR6qA9uk+095tPnWd6szNRqdCOmU7RKQ9j27/hhM=; b=efJX9dW3SCbJIDM2SpWalgcZ/Uxe8phI/eA1OBoDB/tAvsR9ojzTdDCGSKszwceMMj KxqF3itXGMA21fbe8UQe6kusrlNPmnZekek9TkJD0/SyyeUnERm6W5n4O1MRnRCiHUfC KW/mXzxK+gqRWc0ANcvkYl5xXQMRJxvpZpZIwuRh+o9vxQNISekpU/AWls3uEHIfIiv6 kZAXQE6tSirMe261TGF+4ZK+9LjYs65cQdSX3RzNB+WLzWoxFAEZl+fJyK9OE7L/EffJ joEceA2chPjIhFPjH0TGUu8vHJO0zJwgLG8hHBqD2Z0hn9a2HPA/tZSUnISHHC9ZGx67 HOVA== X-Gm-Message-State: ALoCoQkzH0wet+ybIONmSxNUUal1iBi+3zAl5RRMBl2w+yg0EbNEbv3Rah7AqRGlF7wPxVO4Ed2s X-Received: by 10.194.108.202 with SMTP id hm10mr54515283wjb.72.1421623522298; Sun, 18 Jan 2015 15:25:22 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id gu5sm12008122wib.24.2015.01.18.15.25.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Jan 2015 15:25:21 -0800 (PST) Message-ID: <54BC40DE.4020607@multiplay.co.uk> Date: Sun, 18 Jan 2015 23:25:18 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Xin Li , d@delphij.net, svn-src-head@freebsd.org Subject: Re: svn commit: r276123 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs References: <201412230931.sBN9VPMK017968@svn.freebsd.org> <54A35B88.9090102@delphij.net> <54A39153.8040905@freebsd.org> <54A3ACEF.70905@delphij.net> <54A5AC21.5070802@multiplay.co.uk> <54A6DB61.9060607@delphij.net> <54BB2EBB.3090006@multiplay.co.uk> <54BB3EF9.2080701@delphij.net> In-Reply-To: <54BB3EF9.2080701@delphij.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 23:25:30 -0000 On 18/01/2015 05:04, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > > On 1/17/15 19:55, Steven Hartland wrote: >> On 02/01/2015 17:54, Xin Li wrote: >>> Yes, this fixes the problem, thanks for working on it. I'm not >>> fully convinced with the approach though -- shouldn't we update >>> the cachefile (again) when the pool become available? >> Just been looking at this again and when I import a pool which was >> previously unavailable it does write the cache file out. > Well technically it's not an explicit import: the encrypted devices do > not exist at the time the system boots (when zfs tries to update the > cache file, it would not "see" the devices), but they would appear > before 'zfs mount -va' runs by /etc/rc.d/zfs. > >> Do you have some basic reproduction steps for your setup where it >> isn't? > Yes, it's mostly: > > - Create an encrypted GELI provider that is protected by key (or > passphrase, or both, this shouldn't matter). > - Configure in /etc/rc.conf, something like: > > geli_devices="ada1" > geli_default_flags="-k /keys/geli.key -p" > geli_autodetach="NO" > > - Create a pool with ada1.eli (the encrypted provider). > - Reboot twice. > Thanks for that Xin I managed to reproduce what your seeing. Having dug around a looking for the spa config sync triggers, it happens on boot as its root pool. It then only triggers if the config has changed, which it hasn't, and hence why its not resynced when zfs mount -va re-evaluates the availability of all pools via pool_status_check which in turn does an spa_load as the vdev is now available resulting in the pool becoming available. Given this I believe ensuring the sync is clean and doesn't skip unavailable pools is the correct fix, which I've committed as: https://svnweb.freebsd.org/changeset/base/277351 Thanks for helping test, most appreciated :) Regards Steve