From owner-freebsd-fs@FreeBSD.ORG Sat Jan 26 04:26:28 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EC43FE6 for ; Sat, 26 Jan 2013 04:26:28 +0000 (UTC) (envelope-from freebsd@deman.com) Received: from plato.corp.nas.com (plato.corp.nas.com [66.114.32.138]) by mx1.freebsd.org (Postfix) with ESMTP id 8E5A9E35 for ; Sat, 26 Jan 2013 04:26:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by plato.corp.nas.com (Postfix) with ESMTP id 0283612E653F5; Fri, 25 Jan 2013 20:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at corp.nas.com Received: from plato.corp.nas.com ([127.0.0.1]) by localhost (plato.corp.nas.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7a6K8dOrxMd; Fri, 25 Jan 2013 20:26:19 -0800 (PST) Received: from [172.20.10.5] (mobile-166-147-080-234.mycingular.net [166.147.80.234]) by plato.corp.nas.com (Postfix) with ESMTPSA id D354612E653E7; Fri, 25 Jan 2013 20:26:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: RFC: Suggesting ZFS "best practices" in FreeBSD - mapping logical to physical drives From: Michael DeMan In-Reply-To: <20130123085832.GJ30633@server.rulingia.com> Date: Fri, 25 Jan 2013 20:26:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <32F8B97D-DE8D-4876-B127-91BE6AB9A854@deman.com> References: <314B600D-E8E6-4300-B60F-33D5FA5A39CF@sarenet.es> <16E9D784-D2F2-4C55-9138-907BF3957CE8@deman.com> <20130123085832.GJ30633@server.rulingia.com> To: Peter Jeremy X-Mailer: Apple Mail (2.1499) Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 04:26:29 -0000 Except that does not work when the technician just needs to know which = darn physical disk to remove/replace by looking at the front of the box? I think possibly on this thread we are discussing some major topics - = all of which would be good categories within a 'best practices' = document? #1. Best practices for design. #2. Best practices for maintenance (logical) - ZFS 'halt scrub' would = be awesome), when to scrub, etc - how to label your disks, blends into = #3... #3. Best practices for physical maintenance - i.e at the end of the day = ZFS theoretical break down if somebody can't look at the front of the = machine and figure out which disk was the bad one? Maintenance (in my definition) including the scenario where the guy = changing the disk is not necessarily a FreeBSD wizard and = all-knowledgable about gpart, gnop, glabel and such? Some idea that whoever designs, builds, deploys and then maintains the = physical server over a 3-7 year service life - that one person is = supposed to do all of that does not work well either for small = businesses or large businesses? Sorta off topic on this - sorry. On Jan 23, 2013, at 12:58 AM, Peter Jeremy wrote: > On 2013-Jan-22 18:06:27 -0800, Michael DeMan = wrote: >> # OAIMFD 2011.04.13 adding this to force ordering on adaX disks=20 >> # dev.mvs.0.%desc: Marvell 88SX6081 SATA controller=20 >> # dev.mvs.1.%desc: Marvell 88SX6081 SATA controller=20 >>=20 >> hint.scbus.0.at=3D"mvsch0" >> hint.ada.0.at=3D"scbus0"=20 > ... >=20 > That only works until a BIOS or OS change alters the probe order and > reverses the controller numbers. >=20 > The correct solution to the problem is gpart labels - which rely on > on-disk metadata and so don't care about changes in the path to the > disk. >=20 > --=20 > Peter Jeremy