From owner-freebsd-stable@FreeBSD.ORG Fri Jun 14 08:46:51 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 DBDCF9CB for ; Fri, 14 Jun 2013 08:46:51 +0000 (UTC) (envelope-from haramrae@gmail.com) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id AB6CB1C6C for ; Fri, 14 Jun 2013 08:46:51 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id 9so739539iec.5 for ; Fri, 14 Jun 2013 01:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3Wm5h9kzKKuNsUOdWrVAphQ7GNLeUCEiVxoi51NOj2E=; b=Npr40Ek/HCO19Zy5szZ3Q5equHtCf1N65iiiFGoyeKCWIdF6OgItsAC2INFcq4pJt2 SRzoMo3vqsOusIus0JcoaRQMV6v0s8WRuppF0RyjPD7p1MvHe0pOYlJ179QD+dLcItqY egmdNrSVGbJS589HNW5bDk9UnkWSinbMPwrk2D+eTBblMwfVNohKxS6I1adtODVKevQu uAXcRmZlTsFEGJyqKGWUjfkzMJduaWU/AuVlqVD0fvmtlZB5qpi1Pt4LsZGg721tE9Lr QtYZRIjE/dfE8DYHkULKLU24lF5fQQs0Lv9DpcxODt93mr/q8MWqaQax6V9m5SMdIt4G AR3Q== MIME-Version: 1.0 X-Received: by 10.50.129.68 with SMTP id nu4mr548890igb.9.1371199611286; Fri, 14 Jun 2013 01:46:51 -0700 (PDT) Received: by 10.64.128.100 with HTTP; Fri, 14 Jun 2013 01:46:51 -0700 (PDT) In-Reply-To: References: <51B9BB14.6020103@gmail.com> <51BA381C.8070900@gmail.com> <51BAC7D1.70208@gmail.com> <0A53B6AA-9614-42E9-8AA1-82233426EEE6@gsoft.com.au> Date: Fri, 14 Jun 2013 10:46:51 +0200 Message-ID: Subject: Re: zpool labelclear destroys GPT data From: Alban Hertroys To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Johan Hendriks , Kimmo Paasiala , freebsd-stable 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 08:46:51 -0000 On 14 June 2013 10:21, 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.. > Isn't it possible to add such information to labels, so that the tools at least know "who" to ask what they're dealing with? > > 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.. > If there is no guaranteed method of identifying "data" on the disk as a label, then you can't warn the user in all cases. That's not particularly helpful for those cases where you can't warn the user. That's possibly a worse situation than what started this thread. -- If you can't see the forest for the trees, Cut the trees and you'll see there is no forest.