Destroy GPT partition scheme absolutely, how?
Warner Losh
imp at bsdimp.com
Wed Sep 28 19:29:33 UTC 2016
On Wed, Sep 28, 2016 at 1:02 PM, Allan Jude <allanjude at freebsd.org> wrote:
> On 2016-09-27 01:58, Warner Losh wrote:
>> On Mon, Sep 26, 2016 at 11:06 PM, O'Connor, Daniel <darius at dons.net.au> wrote:
>>>
>>>> On 27 Sep 2016, at 14:28, Warner Losh <imp at bsdimp.com> wrote:
>>>> dd of 2MB of zeros to the start and end of the disk. That will destroy
>>>> pretty much everything. For SSDs, sometimes you can do the same with
>>>> TRIMs only faster (other times they are slower or unreliable).
>>>
>>> Yeah, but it would be nicer to not have to know that particular magic incarnation :)
>>
>> Disk formatting has always been 3 parts magic, 2 parts luck and 1 part skill :)
>>
>> It doesn't fit nicely into geom because metadata can live elsewhere.
>>
>> I forgot to add the caveat not to try this on a disk that is part of a
>> RAID volume.
>>
>> Warner
>> _______________________________________________
>> 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"
>>
>
> I wonder if this issue is related at all to the new 'auto resize' gpart
> bits. That leaves the 'uncommitted' transaction pending, and may require
> a 'gpart undo' before the other commands will work correctly.
>
> I wonder if something like 'zpool labelclear', but for gpart would be
> useful, that just nukes the first and last few MB of the disk. I know in
> the installer we jump through a number of hoops to try to clear out old
> stuff, and having one command would be better.
I thought the auto resize stuff was backed out, precisely because it
left bogons around...
Warner
More information about the freebsd-current
mailing list