svn commit: r276123 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Steven Hartland]

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