Date: Sat, 12 Jan 2013 11:36:22 +0100 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: Tim Gustafson <tjg@soe.ucsc.edu> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: Using glabel Message-ID: <20130112113622.0dbd6bc2@fabiankeil.de> In-Reply-To: <CAG27QgTQFA2CvBSrH0Zid9oQg5RbmU55OvfP0njMoLpqHb_GTg@mail.gmail.com> References: <CAG27QgTQFA2CvBSrH0Zid9oQg5RbmU55OvfP0njMoLpqHb_GTg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_//mYt88XJ07moyZVyLAUmetn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Tim Gustafson <tjg@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. >=20 > So, my thinking was along the lines of: >=20 > - 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 --Sig_//mYt88XJ07moyZVyLAUmetn Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlDxPLIACgkQBYqIVf93VJ3VXwCfVSeb1kikeualj2b+s7WAWnyG 8lwAoKzV5PRKAQ9hPkizuWrLxguvZ8z+ =BRyX -----END PGP SIGNATURE----- --Sig_//mYt88XJ07moyZVyLAUmetn--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130112113622.0dbd6bc2>