Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Sep 2015 08:15:05 +0000
From:      Matt Churchyard <matt.churchyard@userve.net>
To:        Chris Stankevitz <chris@stankevitz.com>
Cc:        FreeBSD FS <freebsd-fs@freebsd.org>
Subject:   RE: Name/label/id metadata: how do I make it go away
Message-ID:  <e1abb521ab324532b3445d26984f5638@SERVER.ad.usd-group.com>
In-Reply-To: <5600F0DF.8000805@stankevitz.com>
References:  <56004C68.4020904@stankevitz.com> <alpine.BSF.2.20.1509212126470.4544@wonkity.com> <5600F0DF.8000805@stankevitz.com>

next in thread | previous in thread | raw e-mail | index | archive | help
>Warren/Freddie,

>Thank you for your replies.

>On 9/21/15 8:41 PM, Warren Block wrote:
>>> - gpt id
>>
>> A system-assigned ID in the GPT metadata.  Requires GPT partitioning.

>>> I have a zfs pool of "entire disks".  "zpool status" shows some disks=20
>>> with their daX name (which I prefer) and some with a hideously ugly=20
>>> name such as DISK-%20%20%20%20%20-WD-WMC4NOH1ASDF
>>
>> Disable those labels with kern.geom.label.gptid.enable=3D"0" in=20
>> /boot/loader.conf.

>Combining your two statements quoted above, I believe I can conclude that =
my ZFS "whole disk" drives must have some remnants of GPT left >over from t=
heir previous lives (namely the system-assigned ID in the GPT metadata).

>Surprisingly, these apparently GPT-supplied labels appear to "go away"=20
>when I issue a "glabel stop".  I would not expect this given that Warren e=
xplained that glabels (whose metadata are stored at the end of the >device =
and completely outside the virtual device) are not the same as GPT labels (=
whose metadata are stored within the device on the GPT >metadata).

>I believe one of the following must be true:

>1. It is possible to use "glabel stop" to disable a "GPT system-assigned I=
D" -- even though glabel is a tool for manipulating another style of labels=
.

>2. "glabel stop" only affects glabels.  In my case my drives must contain =
"glables" and not "GPT system-assigned IDs" as Warren guessed.

>3. I misunderstood and glabels/GPS system-assigned IDs are really the same=
 thing.

>Thank you again,

>Chris

The diskid entries have nothing to do with GPT. I suspect your disks do not=
 have any partitioning. These labels are generated automatically based on t=
he actual vendor supplied ID for each disk.

The glabel command allows you to assign a label to a GEOM device, which wil=
l then appear as /dev/label/name. I personally dislike these as they are no=
t portable and are one block smaller than the original device, which is sti=
ll accessible.

It appears glabel is also responsible for identifying various other "labell=
ing" methods that weren't necessary created using the utility. For instance=
 it will create /dev/ufsid/X devices, where X is the ID of a UFS filesystem=
 it has found on a GEOM device. It also seems to be responsible for creatin=
g /dev/gpt entries as well as /dev/diskid, which is possibly why they disap=
pear when you run glabel stop. Most of this is mentioned in the man page, a=
lthough it doesn't mention the diskid entries; There does however appear to=
 be a geom/label/g_label_disk_ident.c source file which implements the /dev=
/diskid/X functionality.

The thing to be clear on is that although glabel is responsible for creatin=
g the device nodes for most of these labels, the way they are assigned is v=
ery different=20

diskid - Automatic based on the ID of the disk - so should reference an ent=
ire disk
gpt - Assigned manually to a partition by GPT partitioning a disk and creat=
ing labelled partitions
gptid - Automatic when you partition a disk with GPT and create partitions =
(every GPT partition has a unique GUID)
glabel - Assigned to any disk or partition manually by using the glabel com=
mand

Interestingly, looking though sysctl, I see options to turn off most label =
devices, but nothing mentions diskid. I don't know if this is actually  mis=
sing, or if one of the existing sysctls also turns them off. (Surely there =
should ideally be a kern.geom.label.diskid.enable?)

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: 1
kern.geom.label.gpt.enable: 1

Regards,
Matt Churchyard





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e1abb521ab324532b3445d26984f5638>