Date: Wed, 03 Oct 2012 17:51:29 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: freebsd-fs@FreeBSD.org Subject: Re: zfs: allow to mount root from a pool not in zpool.cache Message-ID: <506C50F1.40805@FreeBSD.org> In-Reply-To: <DA42C8E9-BFFF-4C5A-9E14-1D50EAEFA669@scsiguy.com> References: <505DE715.8020806@FreeBSD.org> <DA42C8E9-BFFF-4C5A-9E14-1D50EAEFA669@scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
on 23/09/2012 07:59 Justin T. Gibbs said the following: > On Sep 22, 2012, at 10:28 AM, Andriy Gapon <avg@freebsd.org> wrote: > >> >> 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. > > 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. > > 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. For the moment I am trying to think "narrower" to fix the problem at hand :-) But I see what you say. It doesn't make sense that - zfsboot tastes all BIOS visible disks for pools - zfsloader tastes all BIOS visible disks for pools [duplicated effort detected] - but kernel puts its all trust in some cache file I am not sure what performance impact would tasting of all GEOM providers have, but I've got this idea. geom_vdev geoms should taste all providers (like e.g. geom part or label do) and attach (but not g_access) to any that have valid zfs labels. They should cache things like pool guids, vdev guids, txgs, etc. So that that information is readily available for any queries. So we easily know what pools we have in a system, what devices from those pools are available, etc. When we want to import a pool we just start using the corresponding geom_vdev geoms (g_access them). This will also remove a need for a disk tasting done from userland (which is weird on FreeBSD). I think that the zfs+geom part is not too much work. The userland reduction part looks scarier to me :-) -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?506C50F1.40805>