From owner-freebsd-fs@FreeBSD.ORG Mon Oct 24 01:53:26 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 01F6C106566C for ; Mon, 24 Oct 2011 01:53:26 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (lrosenman-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:3ad::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9F1908FC0C for ; Mon, 24 Oct 2011 01:53:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=lerami; h=Content-Type:MIME-Version:References:Message-ID:In-Reply-To:Subject:cc:To:Sender:From:Date; bh=jJuHnIp3eHQ1iLgOcqSSKyIU7dYDEEqdNq1JOMk97v0=; b=miTfYIe/wXoNRex+0Q4NJy6HXSKFlNY4vJROwxGbwIxlkAYrpM+cI9JELPvnP1ShthgWhFYZnYgVjXUEYHg1cHRy6WnYWzcnMgrcv1Sivfz/hevUDEVrUtdv4n/o/FK36lUgsUSteR+M9X2c4sYzOB6cJnzdL/vVF5p4ENTF+mE=; Received: from cpe-72-182-3-73.austin.res.rr.com ([72.182.3.73]:46628 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RI9j9-000Jnk-Ec; Sun, 23 Oct 2011 20:53:25 -0500 Date: Sun, 23 Oct 2011 20:53:22 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: Jeremy Chadwick In-Reply-To: <20111024014616.GA57735@icarus.home.lan> Message-ID: References: <20111024011426.GA57172@icarus.home.lan> <20111024014616.GA57735@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -1.6 (-) X-LERCTR-Spam-Score: -1.6 (-) X-Spam-Report: SpamScore (-1.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FM_MULTI_ODD2=1.1, TW_GP=0.077, TW_PT=0.077, TW_ZF=0.077 X-LERCTR-Spam-Report: SpamScore (-1.6/5.0) ALL_TRUSTED=-1, BAYES_00=-1.9, FM_MULTI_ODD2=1.1, TW_GP=0.077, TW_PT=0.077, TW_ZF=0.077 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:53:26 -0000 On Sun, 23 Oct 2011, Jeremy Chadwick wrote: > 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.debug: 0 kern.geom.label.ext2fs.enable: 1 kern.geom.label.iso9660.enable: 1 kern.geom.label.msdosfs.enable: 1 kern.geom.label.ntfs.enable: 1 kern.geom.label.reiserfs.enable: 1 kern.geom.label.ufs.enable: 1 kern.geom.label.ufsid.enable: 1 kern.geom.label.gptid.enable: 0 kern.geom.label.gpt.enable: 1 > > 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. I believe there is code that I've seen in the gptzfsloader or gptzfsboot code that REMOVES the labels of devices that it finds on the pool. I can't remember exactly where, but I've seen it somewhere. > > 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. It's a "cleanliness" thing. I do see your points. The gptid/* names make zpool status not fit in a default 80x25 screen, but the adaxpy names are ok. It's just annoying, that's all. Thanks for the comments. > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893