From owner-freebsd-stable@FreeBSD.ORG Sat Jan 26 04:21:51 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 138B0F23 for ; Sat, 26 Jan 2013 04:21:51 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7FB9BE04 for ; Sat, 26 Jan 2013 04:21:48 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r0Q4LltE014440; Fri, 25 Jan 2013 23:21:47 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r0Q4LlrM014439; Fri, 25 Jan 2013 23:21:47 -0500 (EST) (envelope-from wollman) Date: Fri, 25 Jan 2013 23:21:47 -0500 (EST) From: Garrett Wollman Message-Id: <201301260421.r0Q4LlrM014439@hergotha.csail.mit.edu> To: wblock@wonkity.com Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD In-Reply-To: References: <20130124174039.GA35811@icarus.home.lan> <20130126025929.GA2777@icarus.home.lan> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Fri, 25 Jan 2013 23:21:47 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 04:21:51 -0000 In article , wblock@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