Re: Destroy GPT partition scheme absolutely, how?

For the whole disk destruction, hopefully one day we'd have BIO_DELETE
coalesce code, so that you can batch of lot of operations into handful SATA
commands. I've heard rumours imp_at_ was doing something along those lines. As
well as SSD disks smart enough to process those requests in the background.
Anyway, just saying. )

-Max

On Tue, Oct 4, 2016 at 10:24 AM, John Baldwin <jhb_at_freebsd.org> wrote:

> On Tuesday, October 04, 2016 06:23:26 AM Warren Block wrote:
> > On Mon, 26 Sep 2016, John Baldwin wrote:
> >
> > > On Tuesday, September 27, 2016 12:36:22 AM Ngie Cooper wrote:
> > >>
> > >>> On Sep 26, 2016, at 22:48, Ernie Luzar <luzar722_at_gmail.com> wrote:
> > >>
> > >> ...
> > >>
> > >>> This little script has been posted before. Maybe it will be what
> your looking for. Called gpart.nuke
> > >>>
> > >>> #! /bin/sh
> > >>> echo "What disk do you want"
> > >>> echo "to wipe? For example - da1 :"
> > >>> read disk
> > >>> echo "OK, in 10 seconds I will destroy all data on $disk!"
> > >>> echo "Press CTRL+C to abort!"
> > >>> sleep 10
> > >>> diskinfo ${disk} | while read disk sectorsize size sectors other
> > >>> do
> > >>> # Delete MBR and partition table.
> > >>> dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
> > >>> # Delete GEOM metadata.
> > >>> dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr
> $sectors - 2` count=2
> > >>> done
> > >>
> > >> Why not just use "gpart destroy -F provider"?
> > >
> > > That doesn't always work.  In particular, if a disk was partitioned
> with GPT
> > > and then you use normal MBR on it afterwards, the 'gpart destroy -F'
> of the
> > > MBR will leave most of the GPT intact and the disk will come up with
> the old
> > > GPT partitions, not as a raw disk.
> >
> > Right.  So do a gpart destroy -F of whatever is on there, ignoring
> > errors, then a gpart create -s gpt.  Now there is definitely a secondary
> > GPT, and a final gpart destroy -F removes it cleanly.
>
> It is usually simpler to just dd zeroes over the first N and last N
> sectors.
> The only fool-proof way to ensure you don't have dangling tables in the
> middle of the disk is to zero the entire disk, but that takes too long.
>
> --
> John Baldwin
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
>