Date: Sun, 7 Oct 2012 12:34:52 -0600 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: freebsd-fs@freebsd.org, Andriy Gapon <avg@freebsd.org> Subject: Re: zfs: allow to mount root from a pool not in zpool.cache Message-ID: <BBD74405-D867-4FE3-AB56-7D2EC026859D@scsiguy.com> In-Reply-To: <20121003085326.GC1386@garage.freebsd.pl> References: <505DE715.8020806@FreeBSD.org> <DA42C8E9-BFFF-4C5A-9E14-1D50EAEFA669@scsiguy.com> <20121003085326.GC1386@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 3, 2012, at 2:53 AM, Pawel Jakub Dawidek <pjd@freebsd.org> wrote: > On Sat, Sep 22, 2012 at 10:59:56PM -0600, Justin T. Gibbs wrote: >> On Sep 22, 2012, at 10:28 AM, Andriy Gapon <avg@freebsd.org> wrote: >>=20 >>>=20 >>> Currently FreeBSD ZFS kernel code doesn't allow to mount root = filesystem on a >>> pool that is not listed in zpool.cache as only pools from the cache = are known to >>> ZFS at that time. >>=20 >> I've for some time been of the opinion that FreeBSD should only use >> the cache file for ZFS pools created from non-GEOM objects (i.e. >> files). GEOM tasting should be used to make the kernel aware of >> all pools whether they be imported on the system, partial, or >> foreign. Even for pools created by files, the user land utilities >> should do nothing more than ask the kernel to "taste them". This >> would remove code duplicated in user land for this task (code that >> must be re-executed in kernel space for validation reasons anyway) >> and also help solve problems we've encountered at Spectra with races >> in fault event processing, spare management, and device arrival and >> departures. >>=20 >> So I'm excited by your work in this area and would encourage you >> to "think larger" than just trying to integrate root pool discovery >> with GEOM. Spectra may even be able to help in this work sometime >> in the near future. >=20 > GEOM tasting would most likely require rewriting the code heavly. > Also note that you can have pools in you system that do match your > hostid, but user decided to keep exported and such pool should not be > configured automatically. Not a huge problem probably as there is pool > status somewhere in the metadata that we can use to see if the pool is > exported or not. This topic came up during ZFS day last week. It turns out that the OS-X port of ZFS already does this and Don Brady said he's happy to share patches. I don't see any reason why this type of solution cannot be upstreamed as well. On Illumos, user land can maintain the cache file and use it to ask the in-kernel ZFS code to "taste" devices, minimizing the amount of divergence. -- Justin=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BBD74405-D867-4FE3-AB56-7D2EC026859D>