From owner-freebsd-stable@FreeBSD.ORG Fri Jun 14 16:03:41 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 08E9BA7C for ; Fri, 14 Jun 2013 16:03:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id D66C71822 for ; Fri, 14 Jun 2013 16:03:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3834DB96F; Fri, 14 Jun 2013 12:03:40 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: zpool labelclear destroys GPT data Date: Fri, 14 Jun 2013 11:49:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <51B9BB14.6020103@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201306141149.14768.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 14 Jun 2013 12:03:40 -0400 (EDT) Cc: Johan Hendriks , Kimmo Paasiala 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: Fri, 14 Jun 2013 16:03:41 -0000 On Friday, June 14, 2013 4:21:08 am Daniel O'Connor wrote: > > On 14/06/2013, at 17:48, Alban Hertroys wrote: > > IMHO it would be helpful to verify what's there first and warn the user about it if such an operation will overwrite a different type of label than what is about to get written there. > > Perhaps it should even refuse to write (by issuing an error stating that there is already a label there - and preferably also what type) until the label that's already there gets explicitly cleared by the user or until the command gets forced. > > Does that make sense? > > The problem with this is that then each label tool needs to know about every other label format you want to detect for.. > > If a label format has a checksum then you could ignore a request to nuke the label if there is no valid checksum (with a flag to force). No idea how many have checksums though.. Well, you could have zpool check if there is a valid ZFS label and prompt/warn if it doesn't find one on whatever device it's about to wipe. That doesn't fix the gmirror/gpt case, but it might make zpool more intuitive to use. -- John Baldwin