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>
index | next in thread | previous in thread | raw e-mail
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. > > Very good point indeed. > > 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. Danielhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A8877555-DBEE-4B6C-A030-BE052D699C18>