Date: Fri, 5 Oct 2012 08:38:49 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: "Justin T. Gibbs" <gibbs@scsiguy.com>, freebsd-fs@FreeBSD.org Subject: Re: zfs: allow to mount root from a pool not in zpool.cache Message-ID: <20121005063848.GC1389@garage.freebsd.pl> In-Reply-To: <506C50F1.40805@FreeBSD.org> References: <505DE715.8020806@FreeBSD.org> <DA42C8E9-BFFF-4C5A-9E14-1D50EAEFA669@scsiguy.com> <506C50F1.40805@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--CblX+4bnyfN0pR09 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 03, 2012 at 05:51:29PM +0300, Andriy Gapon wrote: > 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: > >=20 > >> > >> Currently FreeBSD ZFS kernel code doesn't allow to mount root filesyst= em on a > >> pool that is not listed in zpool.cache as only pools from the cache ar= e 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 > For the moment I am trying to think "narrower" to fix the problem at hand= :-) >=20 > 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 de= tected] > - but kernel puts its all trust in some cache file >=20 > 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 val= id 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, e= tc. When > we want to import a pool we just start using the corresponding geom_vdev = geoms > (g_access them). >=20 > This will also remove a need for a disk tasting done from userland (which= is weird > on FreeBSD). >=20 > I think that the zfs+geom part is not too much work. The userland reduct= ion part > looks scarier to me :-) The original idea behind zpool.cache on Solaris was to reduce boot time and not to taste every single disk/partition in the system if you have few dozens of even few hundred drives in the system. This argument doesn't apply to FreeBSD, as we do the tasting anyway in GEOM. We could eventually try to make it parallel, but this was never big issue for FreeBSD. In my opinion requiring no zpool.cache to import root pool and mount root file system is great idea and we should definiately do it. It will heavly simplify ZFS configuration from various recovery media, etc. User already makes him decision by either placing dataset name into /etc/fstab or by defining vfs.root.mountfrom tunable. There is no need to require anything else from him. He told us what he wants and we should just do it - import the pool even if it is in exported state and if it is not listed in zpool.cache. We already ignore hostid, because it is not available during root mount. I'm all for it. As for the other pools, I'm also in favour of autodetecting them. It will be useful if root is read-only and /boot/zfs/ is read-only as well. But here we need to be more careful. We should only import pool that are in imported state and for which system's hostid matches. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --CblX+4bnyfN0pR09 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBugHgACgkQForvXbEpPzR0rACg4vGbuUatO15KmPihWW9Qqc3s hgsAoPMLGPfHgl0mWsM8oUbvUQpapjQS =EHEJ -----END PGP SIGNATURE----- --CblX+4bnyfN0pR09--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121005063848.GC1389>