From owner-freebsd-fs@FreeBSD.ORG Wed Sep 7 09:42:09 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A781106566C for ; Wed, 7 Sep 2011 09:42:09 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id A7D958FC08 for ; Wed, 7 Sep 2011 09:42:08 +0000 (UTC) Received: from [192.92.129.101] ([192.92.129.101]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p879frWh031522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 7 Sep 2011 12:42:01 +0300 (EEST) (envelope-from daniel@digsys.bg) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1244.3) From: Daniel Kalchev In-Reply-To: <4E673751.5080503@FreeBSD.org> Date: Wed, 7 Sep 2011 12:41:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110907044800.GA96277@server.vk2pj.dyndns.org> <4E673751.5080503@FreeBSD.org> To: freebsd-fs@freebsd.org X-Mailer: Apple Mail (2.1244.3) Subject: Re: "can't load 'kernel'" on ZFS root X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 09:42:09 -0000 On Sep 7, 2011, at 12:20 , Andriy Gapon wrote: > on 07/09/2011 10:35 Artem Belevich said the following: >> It makes me wonder, though -- if we're probing devices anyways, why = is >> zpool.cache existence mandatory? According to the name it's a = *cache*, >> presumably to speed up zpool detection on a normal boot. Perhaps we >> can fall back to probing all drives if zpool.cache is missing. Slower >> boot definitely beats no booting at all. >=20 > Very good point indeed. >=20 > Pawel, Martin, do you know how the relevant code works? I suspect = that you do > :-) Maybe this could be improved trivially?... Imagine, you have an HAST pool, that is currently exported. Exporting = the zpool removes it from the spool.cache, so it is not = recognized/mounted at boot. If your node is a HAST secondary and not = supposed to touch that zpool, then you might accidentally import/use it, = if you ignore the zpool.cache contents. Also, you might not want to import a pool, that is connected to the = server, but not intended for importing. For example, in disaster = recovery. Or if it overlaps with mount points etc. Other than that, perhaps you could consider recognizing pools that = 'belong' to that host, but not present in the cache. Daniel=