From owner-freebsd-fs@FreeBSD.ORG Wed Jun 15 13:00:04 2011 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 432321065675; Wed, 15 Jun 2011 13:00:04 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (ns1.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id 157248FC0A; Wed, 15 Jun 2011 13:00:03 +0000 (UTC) Received: from Justins-MacBook-Pro.local (macbook.scsiguy.com [192.168.0.99]) (authenticated bits=0) by aslan.scsiguy.com (8.14.4/8.14.4) with ESMTP id p5FD1OPG020269 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 15 Jun 2011 07:01:25 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-ID: <4DF8ACD3.1070202@scsiguy.com> Date: Wed, 15 Jun 2011 07:00:03 -0600 From: "Justin T. Gibbs" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4DF7CDD0.8040108@scsiguy.com> <20110615120524.GI1975@garage.freebsd.pl> In-Reply-To: <20110615120524.GI1975@garage.freebsd.pl> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (aslan.scsiguy.com [70.89.174.89]); Wed, 15 Jun 2011 07:01:25 -0600 (MDT) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: fs@FreeBSD.org Subject: Re: [CFR][ZFS] Add "zpool labelclear" command. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:00:04 -0000 On 6/15/11 6:05 AM, Pawel Jakub Dawidek wrote: > On Tue, Jun 14, 2011 at 03:08:32PM -0600, Justin T. Gibbs wrote: > > ZFS rightfully has a lot of safety belts in place to ward off unintended > > data loss. But in some scenarios, the safety belts are so restrictive, > > the only way to proceed is to wipe the label information off of a drive. > > > > Here's an example: > > > > Pull a drive that is active in a pool on one system and stick it into > > another system. ZFS will correctly reject this drive as a member of > > a new pool or as the argument of a replace command. But if you really > > want to use that drive, how do you clear it's "potentially active" > > status? If the pool were imported, you could destroy it, but ZFS wont > > allow you to import a pool unless there are sufficient members for it > > to serve I/O (I know about the undocumented -F option for import, > > but users aren't going to find that). You can use dd to wipe the label > > data off, but where exactly does ZFS keep its for copies of the label? > > In most of the cases like that you can use -f switch, eg. you can create > pool or replace vdev using one that is active when you use that switch. > I'm sure you are aware of this, so I guess it doesn't always work for you? Most of my testing has been on v15, so perhaps the situation is better on v28? On v15, "replace -f" certainly didn't work. Even if "replace -f" does work in v28 (or is made to work), what would be the correct way to just delete the label off of such a drive in the current zpool command set? At Spectra Logic, we've found it very useful in our drive fault testing to be able to easily restore a drive to an unlabeled state in order to verify that ZFSD does the right thing with both labeled and unlabeled drives. If our use case is considered rare, I don't need to push this change back into FreeBSD. However, a quick search indicates that at least some Solaris users have desired a similar command: http://opensolaris.org/jive/thread.jspa?messageID=462337 -- Justin