Corrupt GPT on ZFS full-disks that shouldn't be using GPT

[Quartz]

> Unfortunately on one of the 11 groups I forgot to perform the "gpart
> destroy" step.

OK, well you should still get a readout of all the gpt stuff off the 
disks just to make sure you're not doing something elsewhere that 
actually needs gpt (like labels or something). In this case though you 
can compare the 'good' drives to the 'bad' drives.


> What I means to say was "offline the drive, dd if=/dev/zero
> the drive, then resilver it.

> Do I need to export the pool before using dd on the
> raw device?

Given that this is a raidz3 and you're just going to dd nuke a single 
drive, then no. Just offline the drive first so the pool's not trying to 
use it. Exporting a pool completely shuts it down and packages 
everything up in a machine-independent way so it can be physically moved 
to a new box, but that's overkill for your situation. (Also, I'm not 
100% sure what zfs does when you try to import a pool with one drive 
"missing").


> What I meant here was to say "Perhaps I can politely ask ZFS 'hey if
> you are not using the last 512 bytes of these devices, would you mind
> just filling that with zeros?'".  I would feel more comfortable if
> there was a command like that offered by ZFS rather than me just using
> dd and hoping it doesn't interfere with ZFS.

I *think* that zfs is like other file system partitioning schemes in 
that it just writes from the beginning of the drive and doesn't care 
about the end until it gets there... however don't quote me on it. Again 
though, you could always offline the drive, dd the end, then reattach it 
and do a scrub or something. If you end up blowing away something zfs 
needs, it won't stay silent about it.