From owner-svn-src-all@FreeBSD.ORG Wed Dec 31 08:00:51 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03222AEA; Wed, 31 Dec 2014 08:00:51 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D66D010E9; Wed, 31 Dec 2014 08:00:50 +0000 (UTC) Received: from Xins-MBP.home.us.delphij.net (unknown [IPv6:2601:9:7280:1a80:f08a:f7cb:aaa3:1fd9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 34EA617E95; Wed, 31 Dec 2014 00:00:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1420012849; x=1420027249; bh=+LA7U8DS/0m9SuaYStvZ6XY0eG0VNHkhK7tfKn/o8G4=; h=Date:From:To:Subject:References:In-Reply-To; b=kHFK0uw3uhru9d+T1icfOdgLdIY5j2qbsxyTpP/gtlHoCwg6z5l5K3nPKuPMjb9Q7 jFrKb5GgWxOKpWf7EDD5UGozz7aRxP0I33HGPq8e3SC2vQBeQ3I5jiWtM2AR+N5LKz R92xUPR8N9rX1HRW27XploMEb7iVp6f7GKuQm3t0= Message-ID: <54A3ACEF.70905@delphij.net> Date: Tue, 30 Dec 2014 23:59:43 -0800 From: Xin Li User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Steven Hartland , 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 References: <201412230931.sBN9VPMK017968@svn.freebsd.org> <54A35B88.9090102@delphij.net> <54A39153.8040905@freebsd.org> In-Reply-To: <54A39153.8040905@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 08:00:51 -0000 Hi, Steven, On 12/30/14 22:01, Steven Hartland wrote: > > 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 managed to reproduce this here with mdX backed test pools, and > looking into it this is due to spa_config_sync: > > /* > * Skip over our own pool if we're about to remove > * ourselves from the spa namespace or any pool > that > * is readonly. Since we cannot guarantee that a > * readonly pool would successfully import upon > reboot, > * we don't allow them to be written to the > cache file. > */ > if ((spa == target && removing) || > !spa_writeable(spa)) { > continue; > } > > This was added by upstream: > https://github.com/illumos/illumos-gate/commit/fb02ae025247e3b662600e5a9c1b4c33ecab7d72 > > https://www.illumos.org/issues/3639 > > It seems the desired behavior was to exclude read only pools, to prevent > them being mounted writable on reboot, but the check is too wide and > also excludes unavailable pools too. > > The attached patch corrects the test to only check writable on active > pools so I believe should fix the issue your seeing. > > If you can test it and lmk that would be great. This is an improvement (the attaching of pool is now working) but the cached configuration is somewhat corrupted, it shows many lines of vdev_stats[] contents. I'll take a look at the code tomorrow and see if I can do some instruments and possibly figure out the underlying issue. Cheers,