Using glabel

[Fabian Keil]

Tim Gustafson <tjg at soe.ucsc.edu> wrote:

> We have a few servers with 45 disks each.  It gets a bit cumbersome at
> the moment to map a failed drive (reported via "zpool status") to a
> physical device.  The physical devices are labeled with serial
> numbers, and ZFS reports device nodes.  I was wondering if I could use
> "glabel" to label each of the disks we have with their serial number
> to make identification easier, and then reconfigure the zpool to
> import the drives by gptid, rather than device node.
> 
> So, my thinking was along the lines of:
> 
> - obtain the device serial numbers, probably using smartctl
> - zpool export tank
> - glabel -v SERIAL-NUMBER-0 /dev/ada0
> - glabel -v SERIAL-NUMBER-1 /dev/ada1
> - glabel -v SERIAL-NUMBER-2 /dev/ada2

The "label" action seems to be missing.

> - snip 43 more glabel lines
> - zpool import tank -d /dev/gptid

For labels created with glabel this should be "-d /dev/label tank".
/dev/gptid is for stuff created with gpart.

> Is there any reason that this is a bad idea?  Do I have the command
> sequence correct?

I'm using glabel for geli-encrypted backup pools to automate
the import: http://www.fabiankeil.de/gehacktes/zogftw/

As it works for me, I don't think it's a bad idea in general,
but note that glabel stores the label at the end of the device,
slightly decreasing the space that is available for ZFS.

In my tests ZFS never used the last sectors on a device (as far
as I could tell) but I'm not sure if that's actually guaranteed.

If the last sector on your disks is used by ZFS, creating a label
with glabel on it would overwrite it and importing the pool using
the label would additionally prevent ZFS from even accessing the
sector.

I believe you can test this by comparing the asize shown with
zdb -l and comparing it with the size shown by diskinfo, but
this relies on the asize count starting at the first sector and
due to padding that might not be guaranteed either.

Another problem that has been frequently reported is that
importing the pool without specifying the /dev/label directory
may let ZFS mix labeled devices and labels which renders the
labeling somewhat pointless.

Using geli prevents that of course, but using geli just to
work around this is probably not something you want to do
and also isn't an option for a "live migration".

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20130112/f9db4803/attachment.sig>