Drive labelling with ZFS

[Frank Leonhardt]

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.
>
>
Thanks David. I'd actually tried all the things you suggested, and read 
and re-read the Lucas books which blithely suggest setting GEOM labels 
but without going in to detail. The first chapter is all over the place 
in structure. However, I didn't try the sysctrl tweaks you suggest to 
disable the other methods. I recall the books suggesting that other 
methods are disabled, but without telling you how.

You may well have supplied the missing piece of the jigsaw here. It's a 
shame ZFS can't be told which labelling method to use (or can it?) 
Current situation is less than helpful.

The new SAS enclosure utility in 11.0 is great. It can flash the light 
on any drive you like, but it only takes device names, not GUIDs. And if 
ZFS fails /dev/da87p3 it immediately changes to referring to it by the 
GUID only. I can see why assuming the drive is completely off-line but 
in most cases it's JUST failed, and therefore knowing where it was is 
the same as knowing where it is.

Part of the problem is that zpools created by sysinstall during 
installation are on unlabelled partitions. Actually it does label them, 
but not in any helpful way. </rant>

Regards, Frank.