From owner-freebsd-questions@freebsd.org Wed Sep 23 20:53:36 2015 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2A77A07FBB for ; Wed, 23 Sep 2015 20:53:36 +0000 (UTC) (envelope-from chris@stankevitz.com) Received: from mango.stankevitz.com (mango.stankevitz.com [208.79.93.194]) by mx1.freebsd.org (Postfix) with ESMTP id CE4F81FF3 for ; Wed, 23 Sep 2015 20:53:36 +0000 (UTC) (envelope-from chris@stankevitz.com) Received: from Chriss-MacBook-Pro.local (209-203-101-124.static.twtelecom.net [209.203.101.124]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mango.stankevitz.com (Postfix) with ESMTPSA id 312BC1308; Wed, 23 Sep 2015 13:53:30 -0700 (PDT) Subject: Re: Name/label/id metadata: how do I make it go away To: Paul Kraus , FreeBSD Questions References: <56004C68.4020904@stankevitz.com> <5600F0DF.8000805@stankevitz.com> <5601A82A.7040304@stankevitz.com> <5601B2AF.7040306@stankevitz.com> <5601CB85.8070400@stankevitz.com> <93BD5F1D-9A64-4430-8519-FCF71E817A29@kraus-haus.org> From: Chris Stankevitz Message-ID: <5603114C.2060105@stankevitz.com> Date: Wed, 23 Sep 2015 13:53:32 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <93BD5F1D-9A64-4430-8519-FCF71E817A29@kraus-haus.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2015 20:53:37 -0000 On 9/23/15 10:07 AM, Paul Kraus wrote: > I actually prefer the /dev/diskid/nnn names as those are tied to the > physical drives. By using them I guarantee that even if a drive > physically (or logically if drives or controllers are added) moves > the system can still find and import the zpool. In the early days of > ZFS one of the best ways to damage a zpool was to rearrange drives so > that the ZFS label (and cache) no longer agreed with reality. I was > in the habit of manually exporting critical zpools before making any > hardware changes and after the changes were complete I would import > the pool (sometime with new device names). ZFS _should_ be robust > enough to handle device movement today, but I am slightly paranoid > when it comes to critical data. Paul, I feel the same way about my data. Like you, I am paranoid and I want to understand exactly what is going on. How can I guarantee that my data is safe when I'm at a loss to explain why my "zpool status" is such a mess? Can you tell me how you go about "preferring and using diskids" when you import a zpool? Do you always import on the command line using "zpool import -d"? Thank you, Chris