Date: Wed, 31 Dec 2014 03:33:32 +0000 From: Steven Hartland <steven@multiplay.co.uk> To: d@delphij.net, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r276123 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Message-ID: <54A36E8C.9090908@freebsd.org> In-Reply-To: <54A35B88.9090102@delphij.net> References: <201412230931.sBN9VPMK017968@svn.freebsd.org> <54A35B88.9090102@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31/12/2014 02:12, Xin Li wrote: > On 12/23/14 01:31, Steven Hartland wrote: >> Author: smh >> Date: Tue Dec 23 09:31:24 2014 >> New Revision: 276123 >> URL: https://svnweb.freebsd.org/changeset/base/276123 >> >> Log: >> Always sync the global ZFS config cache to reflect the new mosconfig >> >> This fixes out of date zpool.cache for root pools, which can cause issues >> such as confusion of zdb etc. >> >> MFC after: 1 month >> >> Modified: >> head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c >> >> Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c >> ============================================================================== >> --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c Tue Dec 23 08:51:30 2014 (r276122) >> +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_config.c Tue Dec 23 09:31:24 2014 (r276123) >> @@ -536,8 +536,7 @@ spa_config_update(spa_t *spa, int what) >> /* >> * Update the global config cache to reflect the new mosconfig. >> */ >> - if (!spa->spa_is_root) >> - spa_config_sync(spa, B_FALSE, what != SPA_CONFIG_UPDATE_POOL); >> + spa_config_sync(spa, B_FALSE, what != SPA_CONFIG_UPDATE_POOL); >> >> if (what == SPA_CONFIG_UPDATE_POOL) >> spa_config_update(spa, SPA_CONFIG_UPDATE_VDEVS); > It seems like that this change breaks systems where not all pools are > available (e.g. some of pools are encrypted) at boot time, by removing > all these pools from the cache file. > > As a result, on the next boot, these pools would not be imported even > when the devices are available (geli attached), and reverting this > change would restore the system to its previous behavior. > > Perhaps it have exposed an existing bug? I've seen pools which where unavailable disappear from zpool list and zpool status before this patch, but though it was my imagination as they where test pools I was messing around with, so assumed I'd removed them. Sounds like it wasn't my imagination and it was indeed an existing bug. Does it do it every time for you then Xin? I ask as when I tried to reproduce I couldn't. Regards Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54A36E8C.9090908>