From owner-freebsd-fs@FreeBSD.ORG Sun Oct 7 18:34:56 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B687106566B; Sun, 7 Oct 2012 18:34:56 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (www.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id A9F388FC14; Sun, 7 Oct 2012 18:34:55 +0000 (UTC) Received: from macbook.scsiguy.com (macbook.scsiguy.com [192.168.0.99]) (authenticated bits=0) by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q97IYnnY084421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 7 Oct 2012 12:34:49 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Justin T. Gibbs" In-Reply-To: <20121003085326.GC1386@garage.freebsd.pl> Date: Sun, 7 Oct 2012 12:34:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <505DE715.8020806@FreeBSD.org> <20121003085326.GC1386@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (aslan.scsiguy.com [192.168.0.4]); Sun, 07 Oct 2012 12:34:49 -0600 (MDT) Cc: freebsd-fs@freebsd.org, Andriy Gapon Subject: Re: zfs: allow to mount root from a pool not in zpool.cache X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 18:34:56 -0000 On Oct 3, 2012, at 2:53 AM, Pawel Jakub Dawidek 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 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=