Anyway to change pool to use the gpt label instead of gptid?

[Jeremy Chadwick]

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 |