Corrupt GPT on ZFS full-disks that shouldn't be using GPT
quartz at sneakertech.com
Sun Jun 28 22:10:22 UTC 2015
> 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
> 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.
More information about the freebsd-questions