From owner-svn-src-all@FreeBSD.ORG Wed Dec 31 03:55:32 2014 Return-Path: Delivered-To: svn-src-all@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 A3295CE4 for ; Wed, 31 Dec 2014 03:55:32 +0000 (UTC) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (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 39A661982 for ; Wed, 31 Dec 2014 03:55:31 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id b13so21528682wgh.17 for ; Tue, 30 Dec 2014 19:55:29 -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=INiH7LAfBam5ppnjuekic3EYtb4tZa/sjiKZrLDDTQfiK/YNm2Rc4AFrwy0DLgPpKT K1em8jNnaoLzQgOp3ervP26gaMuv2BWXURLsnwgkyewqhJLmjll1KJRmYTA1G6mGJwFv VKbNvko6w7Wl3GkWDBYnu1kKD51REy5ab9YXVkX+WQDDtdvq8FJQCi727oQ0QAfaJbFQ 2eSpC97Rx2+POhiizNUvwNfh1q4Huu3TVx/ZgGbnUe5rzF38UQX/e1gCmnqOA5NlNqG/ y4Q4dZFSGiAxNvN/zt5Oq9FRpG+38BkiOUqaia081fZi1y7XKn6R9E/FzjYY9Vw+BurM 8fbQ== X-Gm-Message-State: ALoCoQnEZTdD1Bo7nxolI/iBzrx0SrMc29sadobGTGFcRAtizUvRpuzKys0KqFaKyaqwhRt57Not 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-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 03:55:32 -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