Date: Sat, 29 Sep 2012 11:27:24 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: d@delphij.net Cc: freebsd-geom@freebsd.org Subject: Re: Simple way to clear arbitrary drive metadata? Message-ID: <alpine.BSF.2.00.1209291009140.26432@wonkity.com> In-Reply-To: <50663866.9070001@delphij.net> References: <alpine.BSF.2.00.1209281607310.20482@wonkity.com> <50663866.9070001@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1209291009140.26432>