Date: Wed, 7 Sep 2011 12:41:53 +0300 From: Daniel Kalchev <daniel@digsys.bg> To: freebsd-fs@freebsd.org Subject: Re: "can't load 'kernel'" on ZFS root Message-ID: <A8877555-DBEE-4B6C-A030-BE052D699C18@digsys.bg> In-Reply-To: <4E673751.5080503@FreeBSD.org> References: <20110907044800.GA96277@server.vk2pj.dyndns.org> <CAFqOu6jv93WKBLMDKPQCOKfOF6Q4zq6PWKQBjSgfWyVvkM4jFw@mail.gmail.com> <4E673751.5080503@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A8877555-DBEE-4B6C-A030-BE052D699C18>