ZFS pool permanent error question -- errors: Permanent errors have been detected in the following files: storage: <0x0>

[Warren Block]

On Mon, 16 Jun 2014, Anders Jensen-Waud wrote:

> This disk is not the ``storage'' zpool -- it is my ``backup'' pool,
> which is on a different drive:
>
> NAME      SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
> backup    464G   235G   229G    50%  1.00x  ONLINE  -
> storage   928G   841G  87.1G    90%  1.00x  ONLINE  -

What does 'zpool status' say about the device names of that pool?

> Running 'gpt recover /dev/da1' fixes the error above but after a reboot
> it reappears. Would it be better to completely wipe the disk and
> reinitialise it with zfs?

Most likely the problem is that the disk was GPT partitioned, but when 
the pool was created, ZFS was told to use the whole disk (ada0) rather 
than just a partition (ada0p1).  One of the partition tables was 
overwritten by ZFS information.  Possibly this space was mostly unused 
by ZFS, because otherwise a 'gpart recover' would have damaged it.  This 
could also have happened if GPT partitioning was not cleared from the 
disk before using it for ZFS.  ZFS leaves some unused space at the end 
of the disk, enough to not overwrite a backup GPT.  That would be 
detected by GEOM, and not match the primary, which was overwritten by 
ZFS.  The error would be spurious, but attempting a recovery could 
overwrite actual ZFS data.

ZFS works fine on whole disks or in partitions.  But yes, in this case, 
I'd back up, destroy the pool, destroy partition information on the 
drives, then recreate the pool.

A handy way to make sure a backup GPT table is not left on a disk is to 
create and then destroy GPT partitioning:

gpart destroy -F adaN
gpart create -s gpt adaN
gpart destroy adaN