From owner-freebsd-fs@FreeBSD.ORG Sun Sep 23 04:59:57 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A39DE106566C; Sun, 23 Sep 2012 04:59:57 +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 732138FC14; Sun, 23 Sep 2012 04:59:57 +0000 (UTC) Received: from [192.168.0.99] (macbook.scsiguy.com [192.168.0.99]) (authenticated bits=0) by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q8N4xuU3070517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Sep 2012 22:59:56 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: "Justin T. Gibbs" In-Reply-To: <505DE715.8020806@FreeBSD.org> Date: Sat, 22 Sep 2012 22:59:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <505DE715.8020806@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1498) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (aslan.scsiguy.com [192.168.0.4]); Sat, 22 Sep 2012 22:59:56 -0600 (MDT) Cc: freebsd-fs@freebsd.org 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, 23 Sep 2012 04:59:57 -0000 On Sep 22, 2012, at 10:28 AM, Andriy Gapon wrote: >=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. 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. -- Justin