Anyway to change pool to use the gpt label instead of gptid?
Larry Rosenman
ler at lerctr.org
Mon Oct 24 01:53:26 UTC 2011
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 at lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
More information about the freebsd-fs
mailing list