@grwilson
>I personally feel that labelclear should follow the same syntax as other
>'zpool' command. This means we shouldn't introduce /dev/dsk unless we're
>prepared to just change the syntax of 'zpool add', 'zpool create', etc.
>Comparing this to 'zdb' is not a valid argument since most users probably have
>never heard or used 'zdb'.
Agreed. Should there be a "zpool labelread" command that follows the semantics?
>Why can't this just look at the 'whole_disk' property to determine how it
>should treat this device? If a 'whole_disk' is provided but the original pool
>was not created this way, then it should just fail (just like other 'zpool'
>commands would). If a specific platform is not using 'whole_disk' the way it
>was intended then at least this command would behave in a consistent (although
>potentially broken) manner.
Should the labelclear command be dependent on the partition table's still being
intact? I'm concerned we were already making that assumption above, but we're
definitely making it if we need to be able to read whole_disk=0/1 off of a
partition that may not exist. If there were a "zpool autopartition" command,
then that command could be required as a first step if the partition table is
not intact and you want zfs to look in the standard location not just on the
full device. But such a command does not exist at this time.
If there is no GPT found, and the full device was specified, and the device
passes the standard whole_disk check, maybe labelclear should look for and
clear labels on the entire device, and also look for and clear labels in the
"standard location" (where auto-partitioning would put ZFS)?
$ zpool labelclear c0t0d0
$ zpool labelclear /dev/dsk/c0t0d0
$ zpool labelclear /dev/rdsk/c0t0d0
$ zpool labelclear c0t0d0s0
$ zpool labelclear /dev/dsk/c0t0d0s0
$ zpool labelclear /dev/rdsk/c0t0d0s0
Should all six be equivalent? Or should the first three speculate about both
c0t0d0 and c0t0d0s0, while the last three speculate only about c0t0d0s0? Or
something else?
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/32#issuecomment-152858431
_______________________________________________
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer