Name/label/id metadata: how do I make it go away
Matt Churchyard
matt.churchyard at userve.net
Tue Sep 22 08:17:37 UTC 2015
>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
>>> with their daX name (which I prefer) and some with a hideously ugly
>>> name such as DISK-%20%20%20%20%20-WD-WMC4NOH1ASDF
>>
>> Disable those labels with kern.geom.label.gptid.enable="0" in
>> /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 their previous lives (namely the system-assigned ID in the GPT metadata).
>Surprisingly, these apparently GPT-supplied labels appear to "go away"
>when I issue a "glabel stop". I would not expect this given that Warren explained 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 ID" -- 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 the actual vendor supplied ID for each disk.
The glabel command allows you to assign a label to a GEOM device, which will then appear as /dev/label/name. I personally dislike these as they are not portable and are one block smaller than the original device, which is still accessible.
It appears glabel is also responsible for identifying various other "labelling" 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 creating /dev/gpt entries as well as /dev/diskid, which is possibly why they disappear when you run glabel stop. Most of this is mentioned in the man page, although 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 creating the device nodes for most of these labels, the way they are assigned is very different
diskid - Automatic based on the ID of the disk - so should reference an entire disk
gpt - Assigned manually to a partition by GPT partitioning a disk and creating 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 command
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 missing, 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
More information about the freebsd-fs
mailing list