MPS

[Karl Denninger]

On 9/30/2014 12:34 AM, Kevin Oberman wrote:
> On Mon, Sep 29, 2014 at 6:03 PM, Steven Hartland <killing at multiplay.co.uk>
> wrote:
>
>> ----- Original Message ----- From: "Karl Denninger" <karl at denninger.net>
>>
>>> You can also use gpart add with a -l <label>
>>>>
>>> That goes in /dev/gpt though instead of /dev/label :-)
>>>
>> It doesn't have the restrictions that glabel does as far
>> as I know, it just works as long as your using GPT scheme.
>>
>>
>>
>>    Regards
>>    Steve
>>
> I have to agree with Steve. glabel has limitations that causes me to move
> away from it when I moved to head before 10.0. I am trying to remember the
> exact issue, but I know that gpart proved to be a much better solution. I'm
> not sure why /dev/gpt is any different from /dev/label. (Guess that's why
> the smiley.)
> --
> R. Kevin Oberman, Network Engineer, Retired
> E-mail: rkoberman at gmail.com
>
I'd like to understand this, because I've had some trouble trying to
convert on a running machine.  Specifically, I've had instances where
adding labels to existing packs (using gpart modify...) and then
destroying the glabel labels results in ZFS identifying pool members
with their uuid instead of the label -- permanently!

I've yet to have it decide to "lose" a pool member entirely, but
needless to say having a uuid become the "permanent" member identifier
is undesirable.

I've also yet to have glabel screw me PROVIDED I put it on a slice.  But
most of my production machines run encrypted disks since the advent of
AES-NI instruction-set enabled CPUs; so my usual pattern is this:

gpart create....
gpart add -a 4k -t freebsd-zfs da[x]
glabel label yourlabel da[x]p1
geli init -s 4096 -l 256 ...... /dev/label/mylabel

....

zpool create ..... label/mylabel1.eli label/mylabel2.eli .....

Never had this get me in trouble as of yet.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2711 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20140930/6fb1785c/attachment.bin>