In article <alpine.bsf.2.00.1301252014160.37...@wonkity.com>,
wbl...@wonkity.com writes:
>As far as "best practices", situations vary so much that I don't know if
>any drive ID method can be recommended. For a FreeBSD ZFS document, a
>useful sample configuration is going to be small enough that anything
>would work. A survey of the techniques in use at various data centers
>would be interesting.
My best practice would be: write the label onto the drive itself.
Have it be something that is physically meaningful. Then the only
issue is making sure to label a new drive properly when you install
it.
On our big file servers, we use a labeling convention of
s${shelf}d${drive}, where ${shelf} is the rack unit where the shelf is
mounted and ${drive} is the slot number marked on the front of the
drive. I have some scripts to semiautomatically crawl the output of
camcontrol devlist and sas2ircu to determine which drive is located
where. Of course, we have no choice but to label the drives; that's
how gmultipath works.
For bootable drives, we just use the built-in labeling feature of gpt:
the swap partition is named swap0 or swap1, and the ZFS partition is
named tank0 or tank1 (as appropriate for whether it's the primary or
secondary boot device). That way, if one fails on boot, we know which
one it is (or rather, we know which one is still alive).
-GAWollman
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
