On Wed, Sep 28, 2016 at 1:02 PM, Allan Jude <allanj...@freebsd.org> wrote:
> On 2016-09-27 01:58, Warner Losh wrote:
>> On Mon, Sep 26, 2016 at 11:06 PM, O'Connor, Daniel <dar...@dons.net.au>
>>>> On 27 Sep 2016, at 14:28, Warner Losh <i...@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.
>> firstname.lastname@example.org mailing list
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@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...
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"