Drive labelling with ZFS - is this even a good idea?

Frank Leonhardt frank2 at
Fri Jul 7 10:21:19 UTC 2017

On 19/06/2017 14:14, Warren Block wrote:
> On Wed, 14 Jun 2017, Frank Leonhardt wrote:
>> On 14/06/2017 03:02, David Christensen wrote:
>>> On 06/13/2017 04:32 PM, David Christensen wrote:
>>>> Both [1] and [3] discuss the fact that a given drive, partition, file
>>>> system, etc., can be identified in various ways, manual or automatic,
>>>> but the kernel will pick one and "wither" the rest.  Once a GPT 
>>>> label is
>>>> set manually, other methods should be disabled via settings in
>>>> /boot/loader.conf and the system rebooted ([1] p. 35):
>>>>     kern.geom.label.disk_ident.enable="0"
>>>>     kern.geom.label.gptid.enable="0"
>>> Beware that all your disks need to have GPT labels, and those labels 
>>> need to be carried forward into /etc/fstab, etc., before you reboot, 
>>> as the kernel won't be able to find the disks using Disk ID or GPT 
>>> GUID labels once those methods are disabled.
>> Hi David,
>> It turns out that these options were set anyway. The problem turned 
>> out be be that I was assuming that geom label played nice with GPT. 
>> It doesn't! Well it does display labels set on GPT partitions, but it 
>> doesn't change them. It took a look at the GPT blocks to confirm 
>> this. It does, however, mask the GPT version with its own, sometimes, 
>> leading to much monkeyhouse.
>> So ignore glabel completely and set the labels using gpart instead.
> Yes. glabel uses the last block for metadata.  With GPT, the label is 
> inside the partition data and does not take extra space.  Nor is it 
> vulnerable to being overwritten when someone uses the partition device 
> name (/dev/ada0p2) rather than the label name (/dev/label/whatever).
>> Now FreeBSD 11.0 can flash the ident light on any drive you choose, 
>> by device name (as used by ZFS), I'm seriously wondering if labels 
>> are worth the bother if they can't be relied on. Consider what happen 
>> if a tech pulls two drives and puts them back in the wrong order. ZFS 
>> will carry on regardless, but the label will now identify the wrong 
>> slot. Dangerous!
> Right.  This is why I question the reasoning behind static labels for 
> location.  It's really a dynamic thing. 

I'm glad it's not just me then!

This is oft repeated advice taken from a popular book, much of which 
I've come to question over the last few weeks.

Regards, Frank.

More information about the freebsd-questions mailing list