From owner-freebsd-fs@FreeBSD.ORG Mon Oct 24 01:46:20 2011 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 E681A1065675 for ; Mon, 24 Oct 2011 01:46:19 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id 5D78F8FC15 for ; Mon, 24 Oct 2011 01:46:18 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta10.westchester.pa.mail.comcast.net with comcast id oQpX1h0031swQuc5ARmKNP; Mon, 24 Oct 2011 01:46:19 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta15.westchester.pa.mail.comcast.net with comcast id oRmJ1h00t1t3BNj3bRmJVP; Mon, 24 Oct 2011 01:46:19 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C9D45102C1C; Sun, 23 Oct 2011 18:46:16 -0700 (PDT) Date: Sun, 23 Oct 2011 18:46:16 -0700 From: Jeremy Chadwick To: Larry Rosenman Message-ID: <20111024014616.GA57735@icarus.home.lan> References: <20111024011426.GA57172@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: Anyway to change pool to use the gpt label instead of gptid? 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: Mon, 24 Oct 2011 01:46:20 -0000 On Sun, Oct 23, 2011 at 08:24:54PM -0500, Larry Rosenman wrote: > On Sun, 23 Oct 2011, Jeremy Chadwick wrote: > > > > > > >Aren't GPT labels stored in the /dev/gpt directory structure? > Nope, they're eaten: > > $ ls /dev/gpt > swap0 > swap1 > swap2 > swap3 > swap4 > swap5 > $ This looks like a bug or design oddity in GEOM. Based on your setup you should have swap[0-5] and disk[0-5] in /dev/gpt, not just swap[0-5]. > >http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/062999.html > Yep, changed it to the adaxpy form. You're misunderstanding. I'll try to explain it verbosely: kern.geom.label.gptid.enable="0" should, given the variable's description, disable creation of /dev/gptid/XXX entries (GPT IDs). So you set this variable, reboot the system, and guess what ZFS and GEOM does? It tastes the disks, finds the ZFS metadata, and associates each device via the adaXpX naming convention. This is normal. kern.geom.label.gpt.enable="0" (note the difference) should disable creation of /dev/gpt/XXX entries (GPT labels). I assume this variable is set to "1" on your system (the default value), which is why I say I cannot explain why /dev/gpt/disk[0-5] are missing. Use sysctl -d on both of these variables to see their descriptions. I got to thinking about your setup, and I need to ask you: what exactly are you accomplishing by wanting to use GPT labels for ZFS vdev member names? I cease to see what this gains. Here's why I say that. Let's pretend the quirk/problem/bug/whatever above isn't happening and you have lots of entries referencing /dev/gpt/disk[0-5] in your pool. Now one of these things happens: 1. Physical disk ada3 craps out. You replace the disk with a brand new one. You can tell ZFS about ada3p3. Happy days. 2. Physical disk ada3 craps out. You replace the disk and, for whatever reason, the device name changes. Because it's a new/fresh disk with no data on it, even "zpool import" isn't going to see any ZFS metadata on it. Let's say the new device is called "ada9" -- you're going to have to partition this thing anyway manually with gpart to set up your freebsd-boot, freebsd-swap, and freebsd-zfs partitions, right? Which means you already have to know in advance of those commands the disk is called "ada9". So you do your partitioning and you issue "zpool replace zroot ada3p3 ada9p3". Done. 3. Physical disk ada3 craps out. You replace the disk and, for whatever reason, insert what you thought was a new disk but was actually a previously-used disk which already has your above partitioning scheme on it. ZFS isn't going to magically start using the ZFS bits in ada3p3; you have to manually issue the command "zpool replace zroot ada3p3" and it will resilver/overwrite the "old" stuff that was there. I can continue to list off some more "sub-examples" of #3, but the fact of the matter is, ZFS on FreeBSD defaults to having pools with the "autoreplace" property disabled, so automatic resilver/rebuild won't happen on insertion. In fact, I'm under the impression "autoreplace" doesn't work on FreeBSD (how would CAM/GEOM/etc. "inform" ZFS?) So these are the only 3 scenarios I can think of. Am I missing one that somehow justifies the use of GPT labels named "diskX" when you already have things effectively called that (adaXpX)? I don't see the positives. Let me know, I'm quite curious. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |