From owner-freebsd-stable@FreeBSD.ORG Fri Jun 14 08:18:31 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 02106F3E for ; Fri, 14 Jun 2013 08:18:31 +0000 (UTC) (envelope-from haramrae@gmail.com) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id C775A1B29 for ; Fri, 14 Jun 2013 08:18:30 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id e11so721369iej.1 for ; Fri, 14 Jun 2013 01:18:30 -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=deA0SKgFQFdN3UknmSTNVn/yPpZGzD4leu7SAFhQkew=; b=FZCWupYbJ88WGLcOjuKYKY2Z+mGsaWRlXarYzO6HnWaDIcc5fC5Q/UYdyaz3Zqcsfc 4K8WXMunVROUyh1pHT6npGL5wtsSnaX/OqWsoweYsSTMW87lvfLojJlRo6dIm+fv2m6X fJH2TY7dWalRK6XfOAN+gXFjJ9j/DMzsniCIlIXJnRwzZUGvpZdzWyacvoyEXebwDs+V e+yDqaH3+u2QZNzdmSOowhhPvkgZsDNJ23sDFn5DsNXuqOaGZzFbmvr5gVthu8EcpnB3 vCIMaGtcjWfeJ122m8V11zUULNWdyOe+8fIlYrJN4GfySVTyiFjWcqB4L2FCIrqyfuYK 707g== MIME-Version: 1.0 X-Received: by 10.50.102.101 with SMTP id fn5mr494257igb.22.1371197909965; Fri, 14 Jun 2013 01:18:29 -0700 (PDT) Received: by 10.64.128.100 with HTTP; Fri, 14 Jun 2013 01:18:29 -0700 (PDT) In-Reply-To: <0A53B6AA-9614-42E9-8AA1-82233426EEE6@gsoft.com.au> 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:18:29 +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:18:31 -0000 On 14 June 2013 10:02, Daniel O'Connor wrote: > > On 14/06/2013, at 17:05, Johan Hendriks wrote: > >> Of course, zpool(8) will do exactly what you tell it to do. It does > >> not know about any partitioning schemes and assumes that the user > >> knows that using labelclear on a the whole disk will potentially > >> destroy all data on it including any partitioning information. > >> > > Well as i found out, zpool(8) does not know what it clears. ! :D > > > > I think an adjustment to the man page is in order here. > > The man page clearly state it removes ZFS labels, not GPT, gmirror and > glabel labels. > > It should mention it will remove labels from the disk/device, and that > it clears ALL labels. > > > > If a user reads the man page it now looks save to use labelclear. > > I thougt that zpool would know if there was zpool label information on > the disk, and if i a case there is no ZFS label information it will tell me > that! > > In my case i did not loose anything, so no big deal but there will > proberbly be someone who gets bitten by this. > > > > A plus is that i found a new way to clear my disks fast ! ;) > > > It only clears ZFS labels, just because GPT & gmirror information sits in > a similar place doesn't make that incorrect. > > You are saying the equivalent of.. > Why does "dd if=/dev/zero of=/dev/da0" erase my whole disk, not just the > first partition? > > ie you are giving the tool bad options and then complaining when it > doesn't do what you meant :) > > Perhaps it should be modified to check if there is valid ZFS data there > before proceeding (although that could be annoying unless there is a way to > force it), and/or the man page could be amended to say it doesn't do any > checks before erasing things. > The same goes for several geom labels. For example, if you write a geom_mirror label to a GPT-partitioned disk (as opposed to writing it to a partition within that disk), you overwrite the backup GPT table. I got recently warned not to do that (it didn't apply in my case, but still). 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? If you can't see the forest for the trees, Cut the trees and you'll see there is no forest.