From owner-freebsd-stable@FreeBSD.ORG Sat Jan 26 02:59:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1C55AE5E for ; Sat, 26 Jan 2013 02:59:31 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by mx1.freebsd.org (Postfix) with ESMTP id DFB5A9F0 for ; Sat, 26 Jan 2013 02:59:30 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta13.emeryville.ca.mail.comcast.net with comcast id sSHD1k0031eYJf8ADSzWl2; Sat, 26 Jan 2013 02:59:30 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta19.emeryville.ca.mail.comcast.net with comcast id sSzV1k0051t3BNj01SzVla; Sat, 26 Jan 2013 02:59:29 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1387A73A1B; Fri, 25 Jan 2013 18:59:29 -0800 (PST) Date: Fri, 25 Jan 2013 18:59:29 -0800 From: Jeremy Chadwick To: Warren Block Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD Message-ID: <20130126025929.GA2777@icarus.home.lan> References: <20130124174039.GA35811@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359169170; bh=MBnOfd20Lcx7hymXZDgpZNo4ECziWEH4OhXiFXc8zvs=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=gO5nGor4CGJo6EsTOKnaYSDDJMgzLoQlWzE0DLhhpd+DGgc8Krefqtc70QgY3MgJG z+Sk7yVSbaJa5oiyDfdcs8y4J1YJpO+i94tXz8k8FpiRGY9EA07G59HqHcPwYIMwr6 iG5MJutqaFyyCu+g+f//HHWMrWVARmRglH0sNDz/04p84I3R9OvRD7u2ck68U0vlBS DCokh4g1CCiEpqYkGP4fw7kpZUl4gWhnhDulAFS0GPtBQ/ueql9x+YZB0bCEZ8+jEO ckpoYPHLI40UPkJcd0cRE5HQgpCE1TqyPEbpX8ZmGceegjW5GkyZ74rE/5laSX+YLr 3qaPxTgUWjC4A== Cc: freebsd@deman.com, freebsd-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 02:59:31 -0000 On Fri, Jan 25, 2013 at 12:58:15PM -0700, Warren Block wrote: > On Thu, 24 Jan 2013, Jeremy Chadwick wrote: > > >>>#1. Map the physical drive slots to how they show up in FBSD so if a > >>>disk is removed and the machine is rebooted all the disks after that > >>>removed one do not have an 'off by one error'. i.e. if you have > >>>ada0-ada14 and remove ada8 then reboot - normally FBSD skips that > >>>missing ada8 drive and the next drive (that used to be ada9) is now > >>>called ada8 and so on... > >> > >>How do you do that? If I'm in that situation, I think I could find the > >>bad drive, or at least the good ones, with diskinfo and the drive serial > >>number. One suggestion I saw somewhere was to use disk serial numbers > >>for label values. > > > >The term FreeBSD uses for this is called "wiring down" or "wired down", > >and is documented in CAM(4). It's come up repeatedly over the years but > >for whatever reason people overlook it or can't find it. > > I was aware of it, it just seems like there ought to be a better way > to identify drives than by messing with the hardware configuration. I understand what you mean, but it's actually messing with a software configuration (specifically CAM). It's a one-time change that solves the dilemma; it only has to be adjusted if you change controller brands or models, which is a lot less often than changing disks. > Something more elegant, less tied to changing the hardware > configuration of the host. Assigning the drive serial number as a > label, for example. Hmm... all this does is change the nature of the problem, no? You still have the issue of "having to know some magical number" to determine out what path name refers to what physical disk in your system. Can you expand on how this would solve it? As for a unique number per disk, disks within the past ~5 years (SATA, SAS, and some SCSI) all tend to have this: it's called a WWN: http://en.wikipedia.org/wiki/World_Wide_Name But older ATA disks (and by older I don't mean ancient, I mean even semi-old) may not have this, which means you get to use something else. UUIDs come to mind, but then the question becomes what do you base the generation off of? Model string + serial number + firmware? There are also complexities depending on HBAs (disk controllers) as well; I've seen references, at least on Solaris, of people having one disk showing up twice across 2 separate controllers (i.e. only 1 physical disk in the machine, but showing up as both c8d0 and c9d0, both with the same model string and serial number). I imagine some RAID controllers would do this (when a drive isn't part of an array; it might show up as both /dev/adaX and /dev/somedriverX). I know at some point I saw this with FreeBSD too during an OS install, I just can't remember what the names were that I saw. Linux has by-uuid and by-id (the latter is what you'd like), but there are caveats to that too: https://wiki.archlinux.org/index.php/Persistent_block_device_naming http://www.terabyteunlimited.com/kb/article.php?id=389 So at the end of the day I prefer CAM's "wired down" method -- the reason is that by modifying loader.conf I **know for sure** bay/cable X maps to /dev/adaX, and it's a one-time deal until I decide to move from my ICH9 controller to, say, an Areca. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |