Date: Sat, 12 Dec 2015 11:26:39 -0700 From: Ian Lepore <ian@freebsd.org> To: "Andrey V. Elsukov" <ae@FreeBSD.org>, Alexey Dokuchaev <danfe@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r292058 - head/sbin/geom/class/part Message-ID: <1449944799.1358.160.camel@freebsd.org> In-Reply-To: <566C6307.70200@FreeBSD.org> References: <201512101037.tBAAbDMq065138@repo.freebsd.org> <1449767147.1358.62.camel@freebsd.org> <5669B969.5020605@FreeBSD.org> <20151212121209.GA60800@FreeBSD.org> <1449940829.1358.154.camel@freebsd.org> <566C6307.70200@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2015-12-12 at 21:10 +0300, Andrey V. Elsukov wrote: > On 12.12.15 20:20, Ian Lepore wrote: > > I spent much of the last week fighting with "geom destroy" and > > trying > > to prevent the ressurection of old geoms during the creation of new > > ones. It's a Big Mess and it doesn't really work well at all. I > > came > > to the conclusion that it's not geom destroy that needs a force > > flag so > > much as geom create, where it would mean "it is okay to replace any > > existing geom with the new one." > > Let's be honest. This problem is completely unrelated to what I > committed. > Oh yeah, totally. One of the first things I discovered about this problem was that dd'ing some zeroes (where some < the whole device) didn't help. But 'destroy -F' was mentioned in a panacea-like way, andit's not really all that. I don't think I'll bother to reply to the rest, since it seemed to be saying basically "raw data is available to you and beyond that this stuff is supposed to be hard to work with". -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1449944799.1358.160.camel>