Date: Sun, 23 Oct 2011 20:53:22 -0500 (CDT) From: Larry Rosenman <ler@lerctr.org> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-fs@freebsd.org Subject: Re: Anyway to change pool to use the gpt label instead of gptid? Message-ID: <alpine.BSF.2.00.1110232049490.12412@borg> In-Reply-To: <20111024014616.GA57735@icarus.home.lan> References: <alpine.BSF.2.00.1110231949380.65073@borg> <20111024011426.GA57172@icarus.home.lan> <alpine.BSF.2.00.1110232023400.12166@borg> <20111024014616.GA57735@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1110232049490.12412>