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
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
