From owner-freebsd-geom@FreeBSD.ORG Sat Sep 29 17:27:31 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C764106564A for ; Sat, 29 Sep 2012 17:27:31 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD588FC08 for ; Sat, 29 Sep 2012 17:27:31 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q8THROmr026771; Sat, 29 Sep 2012 11:27:24 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q8THROqL026768; Sat, 29 Sep 2012 11:27:24 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sat, 29 Sep 2012 11:27:24 -0600 (MDT) From: Warren Block To: d@delphij.net In-Reply-To: <50663866.9070001@delphij.net> Message-ID: References: <50663866.9070001@delphij.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sat, 29 Sep 2012 11:27:24 -0600 (MDT) Cc: freebsd-geom@freebsd.org Subject: Re: Simple way to clear arbitrary drive metadata? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 17:27:31 -0000 On Fri, 28 Sep 2012, Xin Li wrote: > On 09/28/12 15:21, Warren Block wrote: >> Last night, I found that the remnants of a GPT backup table on an >> MBR drive prevented it from booting. When reusing drives from old >> mirrors, old mirror metadata can be a problem also. And there may >> be old hardware RAID metadata at the end of the drive. >> >> It would be great if dd understood negative seek values. This >> would get most of that old metadata: >> >> dd if=/dev/zero of=/dev/ada8 seek=-34 >> >> ...but dd does not understand negative seek values. (Been on my >> list for a while to look at that.) >> >> Which leaves things like >> >> diskinfo ada8 | cut -f4 (subtract 34) dd if=/dev/zero of=/dev/ada8 >> seek=(calculated value) >> >> That can be done in one command line with bc and backticks, but >> it's not clear or elegant. gpart can clear secondary GPT tables, >> but I'm pretty sure it won't wipe out that space unless it actually >> is a GPT table. Likewise with glabel and gmirror, they're safe >> because they only touch data they understand. >> >> Is there something simpler and more blunt? > > I think you can do: > > gpart destroy -F ada8 > gpart create -s gpt ada8 > gpart destroy -F ada8 > > The second 'create' will write an empty partition table to the > secondary table. Nice! It works perfectly for GPT and glabel metadata. gmirror is a problem. If the gmirror kernel module is loaded, drives with gmirror metadata create a mirror. GEOM prevents writes to the drive then. sysctl kern.geom.debugflags=16 allows writes, but the mirror is still in memory and running. 'gmirror stop' (which the system also does on shutdown) helpfully writes the whole metadata block back to the drive. After reboot, it's right back where it was. Seems like the only way to deal with gmirror is to have the user check for it directly, and stop the mirror if the attached drive is a member. Probably the same for graid, but I don't know if I have a system where I can test that.