Date: Mon, 01 Oct 2012 14:10:40 +0400 From: Konstantin Kukushkin <dark@rambler-co.ru> To: Warren Block <wblock@wonkity.com> Cc: d@delphij.net, freebsd-geom@freebsd.org Subject: Re: Simple way to clear arbitrary drive metadata? Message-ID: <50696C20.3020704@rambler-co.ru> In-Reply-To: <alpine.BSF.2.00.1209291009140.26432@wonkity.com> References: <alpine.BSF.2.00.1209281607310.20482@wonkity.com> <50663866.9070001@delphij.net> <alpine.BSF.2.00.1209291009140.26432@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
29.09.2012 21:27, Warren Block пишет: > 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. You may use 'geom <class> clear' command to clear metadata from disk/partition/other GEOM provider. This will work only on stopped mirrors or while geom_mirror not loaded, of course. For gmirror you can 'remove' component from running mirror (even if the component is last). Metadata will cleared after removing, so gmirror remove <mirror_name> <component_name>' is very usable. You can determine what GEOMs metadata living on disk $disk using command 'geom <class> dump', like this: for class in mirror stripe concat raid3; do geom $class dump $disk done > Probably the same for graid, but I don't know if I have a system where I > can test that. > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" -- С уважением, Константин Кукушкин, Rambler Internet Holding mailto:dark@rambler-co.ru тел.: 8 (495) 785-17-00#2129
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50696C20.3020704>