Date: Sun, 18 Jan 2015 23:25:18 +0000 From: Steven Hartland <steven@multiplay.co.uk> To: Xin Li <delphij@delphij.net>, d@delphij.net, svn-src-head@freebsd.org Subject: Re: svn commit: r276123 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Message-ID: <54BC40DE.4020607@multiplay.co.uk> In-Reply-To: <54BB3EF9.2080701@delphij.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54BC40DE.4020607>