From owner-freebsd-fs@FreeBSD.ORG Wed Jun 15 12:05:40 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 1DFD91065677 for ; Wed, 15 Jun 2011 12:05:40 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 927D58FC0C for ; Wed, 15 Jun 2011 12:05:39 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0F2B645CD9; Wed, 15 Jun 2011 14:05:37 +0200 (CEST) Received: from localhost (58.wheelsystems.com [83.12.187.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 34CF545C8C; Wed, 15 Jun 2011 14:05:27 +0200 (CEST) Date: Wed, 15 Jun 2011 14:05:24 +0200 From: Pawel Jakub Dawidek To: "Justin T. Gibbs" Message-ID: <20110615120524.GI1975@garage.freebsd.pl> References: <4DF7CDD0.8040108@scsiguy.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UthUFkbMtH2ceUK2" Content-Disposition: inline In-Reply-To: <4DF7CDD0.8040108@scsiguy.com> X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-3.9 required=4.5 tests=ALL_TRUSTED,BAYES_00, RCVD_IN_SORBS_DUL autolearn=ham version=3.0.4 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 12:05:40 -0000 --UthUFkbMtH2ceUK2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > Here's an example: >=20 > 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? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --UthUFkbMtH2ceUK2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk34oAQACgkQForvXbEpPzTMPQCfdOF/B55vnF1dEVZpS5/ZFyAd PGQAnR/Mq+I8jT8plWA2axWUoBE9Y+Fc =yrzz -----END PGP SIGNATURE----- --UthUFkbMtH2ceUK2--