From owner-svn-src-head@FreeBSD.ORG Wed Dec 31 03:33:53 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2CED39A0 for ; Wed, 31 Dec 2014 03:33:53 +0000 (UTC) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC82816D5 for ; Wed, 31 Dec 2014 03:33:52 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id r20so26463037wiv.4 for ; Tue, 30 Dec 2014 19:33:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OUMHyAP7wBgUEvXi2ze0wPEdetsbIoPCMsKQnXO2xHU=; b=MH9sm445ecyJgi18oH0W/cx7vGeGysXVM+DPqcEBttgb2oQ9JU017rFnxnkTh14ZDY FctmJ5oOqfizIxfso12v6F99X8mnDD9auAgf7LhAojR2Y2sUu6p28MRC0IWX13S6UcHH RbYroiFjynJM5vFcAFgMt9uNud4m/Ywl4bYlZNhR6lJrvptTjagXDvW3LgRrmH8sgkgy jnfQgfNjz7vsGqRtsa6jRNZ/Y5oxzdkVpVhYY7819KLOuOIEB55BqCFxeLQYr6I3rUPE mOFOvaHKplWLeZdbcX8ImYlin1XtPlVZh/pWlRF6EjaT4RioqAxjaM+9/qJ80B34Nunm WgUQ== X-Gm-Message-State: ALoCoQmL0gnht3bnWfl9cdVne/cWUIs12YLBquxrIIXiuxH+JrmzjVORz54owcb38N8AEI3iC7n3 X-Received: by 10.181.13.7 with SMTP id eu7mr113866888wid.72.1419996825198; Tue, 30 Dec 2014 19:33:45 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id bs2sm55995892wjc.43.2014.12.30.19.33.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Dec 2014 19:33:44 -0800 (PST) From: Steven Hartland X-Google-Original-From: Steven Hartland Message-ID: <54A36E8C.9090908@freebsd.org> Date: Wed, 31 Dec 2014 03:33:32 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 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 References: <201412230931.sBN9VPMK017968@svn.freebsd.org> <54A35B88.9090102@delphij.net> In-Reply-To: <54A35B88.9090102@delphij.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2014 03:33:53 -0000 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