Re: zpool labelclear destroys GPT data

On 14 June 2013 10:02, Daniel O'Connor <doconnor@gsoft.com.au> wrote:

>
> On 14/06/2013, at 17:05, Johan Hendriks <joh.hendriks@gmail.com> wrote:
> >> Of course, zpool(8) will do exactly what you tell it to do. It does
> >> not know about any partitioning schemes and assumes that the user
> >> knows that using labelclear on a the whole disk will potentially
> >> destroy all data on it including any partitioning information.
> >>
> > Well as i found out, zpool(8) does not know what it clears. ! :D
> >
> > I think an adjustment to the man page is in order here.
> > The man page clearly state it removes ZFS labels, not GPT, gmirror and
> glabel labels.
> > It should mention it will remove labels from the disk/device, and that
> it clears ALL labels.
> >
> > If a user reads the man page it now looks save to use labelclear.
> > I thougt that zpool would know if there was zpool label information on
> the disk, and if i a case there is no ZFS label information it will tell me
> that!
> > In my case i did not loose anything, so no big deal but there will
> proberbly be someone who gets bitten by this.
> >
> > A plus is that  i found a new way to clear my disks fast ! ;)
>
>
> It only clears ZFS labels, just because GPT & gmirror information sits in
> a similar place doesn't make that incorrect.
>
> You are saying the equivalent of..
> Why does "dd if=/dev/zero of=/dev/da0" erase my whole disk, not just the
> first partition?
>
> ie you are giving the tool bad options and then complaining when it
> doesn't do what you meant :)
>
> Perhaps it should be modified to check if there is valid ZFS data there
> before proceeding (although that could be annoying unless there is a way to
> force it), and/or the man page could be amended to say it doesn't do any
> checks before erasing things.
>

The same goes for several geom labels. For example, if you write a
geom_mirror label to a GPT-partitioned disk (as opposed to writing it to a
partition within that disk), you overwrite the backup GPT table. I got
recently warned not to do that (it didn't apply in my case, but still).

IMHO it would be helpful to verify what's there first and warn the user
about it if such an operation will overwrite a different type of label than
what is about to get written there.
Perhaps it should even refuse to write (by issuing an error stating that
there is already a label there - and preferably also what type) until the
label that's already there gets explicitly cleared by the user or until the
command gets forced.
Does that make sense?

If you can't see the forest for the trees,
Cut the trees and you'll see there is no forest.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"