Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 15 Jun 2013 14:39:19 +0300
From:      Daniel Kalchev <daniel@digsys.bg>
To:        "freebsd-stable@freebsd.org Stable" <freebsd-stable@freebsd.org>
Subject:   Re: zpool labelclear destroys GPT data
Message-ID:  <6CE4EA1C-35AD-4B32-9863-88307FCD8141@digsys.bg>
In-Reply-To: <CAFHbX1JdHV%2B1DhRd%2BVpAQRAOXK8CUU7_X%2B-=RrPtEmnG4%2BuVGQ@mail.gmail.com>
References:  <51B9BB14.6020103@gmail.com> <CAF-3MvOtM6%2Bk1bOWLUMY_-zmWCWbX98hGhj8kTJsWURTKEZxPQ@mail.gmail.com> <B92714FF-CE1A-44B8-9284-C12429FA42D7@gsoft.com.au> <201306141149.14768.jhb@freebsd.org> <CAFHbX1JdHV%2B1DhRd%2BVpAQRAOXK8CUU7_X%2B-=RrPtEmnG4%2BuVGQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On 14.06.2013, at 19:16, Tom Evans <tevans.uk@googlemail.com> wrote:

>=20
> I suppose if labelclear was made to check for the existence of a
> pre-existing ZFS label, the force flag could be used to force the
> change=85 I still don't like it, the command is not called
> labelclear-only-if-the-label-area-already-has-sane-data.

It apparently does, because zpool labelclear would refuse to wipe a =
label that it believes belongs to an active zpool. So it apparently does =
check data. Just applies some weird logic.

The logic is also flawed and annoyed me few times. For example, you want =
to remove a drive from an raidz. You do this by marking the drive =
offline and wiping it's ZFS labels, so that you can "repurpose it". =
However, as long as the zpool is not exported, zpool labelclear  refuses =
to wipe labels and you re forced to resort to dd.
Why would it refuse to clear labels on an offlined drive? Is there =
better method?

Daniel=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6CE4EA1C-35AD-4B32-9863-88307FCD8141>