GPT Rejected - how to wipe for ZFS?

I'm setting up a RAIDZ2 pool on a NAS I've built and I have one disk throwing the "GPT Invalid or corrupt" error. As I understand it, I can use ZFS on raw disks without partitioning and would prefer, if possible, to just remove the partition table on this disk (or all of my disks, for that matter) and let ZFS handle everything.

Either way, I'd prefer not to have a zpool with one disk exhibiting a problem that none of the rest are. What's the best way to get rid of this error and make sure my disks are uniform so as not to cause problems with ZFS?
 
Use gpart(8) to destroy the existing partitioning information. It might be necessary to use recover first. Then use gpart destroy to destroy the now-valid GPT, including the backup table at the end of the disk which was probably the problem.
 
You can also use zpool labelclear on each disk to make sure there are no ZFS-related pseudo-GPT tables on it.

And gpart -F is useful as a "nuke it from orbit" option. Combined with the labelclear, you should have "pristine" disks for use with ZFS.

If you really want to make sure the disk is completely clean, you can use dd if=/dev/zero of=/dev/XXXX bs=1M to completely zero out every sector of the disk, including any partitioning info at the front and end of the disk.
 
Use gpart(8) to destroy the existing partitioning information. It might be necessary to use recover first. Then use gpart destroy to destroy the now-valid GPT, including the backup table at the end of the disk which was probably the problem.

That is exactly what I was looking for. Will gpart destroy -F da3 also work in a live Raid-Z2 array (in principle) or is it better to remove the drive, attach it to another machine kill the GPT table and reattach it to the array?

Will "killing" the GPT table result in resilvering of the drive in the Raid-Z2 array?

Thank you very much!

Georg
 
That is exactly what I was looking for. Will gpart destroy -F da3 also work in a live Raid-Z2 array (in principle) or is it better to remove the drive, attach it to another machine kill the GPT table and reattach it to the array?

If the GEOM system will allow it... That will depend on whether the ZFS array is using the GPT provider. Still potentially dangerous. I'd trust gpart(8) to only erase the GPT primary and secondary tables, but I'm not sure if that would upset ZFS. I am pretty sure I would not do this to a disk without making sure it did a resilver, it seems unsafe for the data on that disk otherwise.

Will "killing" the GPT table result in resilvering of the drive in the Raid-Z2 array?

Maybe. That could be a good thing, because then at least there would be a known-good copy of information on the modified drive.
 
Hi Warren (?, if you are you the Warren with the How to use FreeBSD with SSD-guide)

Thanks for your answer.

dmesg shows that the GPT table of da3 ist invalid. When I try

Code:
gpart show da3
I just receive "gpart: No such geom: da3". When I try gpart destroy da3, I receive "gpart: arg0 'da3': Invalid argument". Am I doing anything wrong?

Georg
 
What usually happens is a disk has GPT partitioning, with a table at the start of the disk and the backup table at the end. Then some other partitioning, usually MBR, is installed without removing the GPT, so a new table overwrites the primary GPT at the start of the disk but leaves the backup table still present at the end. gpart recover can (sometimes) bring back a valid GPT setup, copying the backup GPT to the primary, and then gpart destroy can be used to remove both. This is not guaranteed to leave ZFS data untouched. Likewise with using dd(1) to overwrite the last 34 (or 35, I forget) blocks of the disk. zpool labelclear will definitely erase the ZFS label that identifies the drive as part of a ZFS array. I'm not entirely sure it will clear that backup GPT table, though.

(Yes, I have some articles on FreeBSD at http://www.wonkity.com/~wblock/docs/.)
 
Back
Top