Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 15 Jun 2013 13:03:15 +0100
From:      "Steven Hartland" <killing@multiplay.co.uk>
To:        "Daniel Kalchev" <daniel@digsys.bg>, <freebsd-stable@freebsd.org>
Subject:   Re: zpool labelclear destroys GPT data
Message-ID:  <C02A2192689D49D6A62B384F0FDD97DB@multiplay.co.uk>
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> <6CE4EA1C-35AD-4B32-9863-88307FCD8141@digsys.bg>

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

----- Original Message ----- 
From: "Daniel Kalchev" <daniel@digsys.bg>
To: <freebsd-stable@freebsd.org>
Sent: Saturday, June 15, 2013 12:39 PM
Subject: Re: zpool labelclear destroys GPT data


>
> On 14.06.2013, at 19:16, Tom Evans <tevans.uk@googlemail.com> wrote:
>
>>
>> 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… 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?

I'd recommend raising a bug report and posting on the on illumos zfs list
for this so its specific behavour can be discussed there, as it does
sound odd to me and should in theory be quite an easy fix.

    Regards
    Steve 


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C02A2192689D49D6A62B384F0FDD97DB>