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

[Tom Evans]

On Mon, Jun 16, 2014 at 3:49 AM, Anders Jensen-Waud
<anders at jensenwaud.com> wrote:
> 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?
>
> Miraculously, an overnight 'zpool scrub storage' has wiped out the errors
> from yesterday, and I am puzzled why that is the case. As per the
> original zpool status from yesterday, ZFS warned that I needed to
> recover all the files from backup
>
> aj at beastie> zpool status                                                                                                ~
>   pool: backup
>  state: ONLINE
>   scan: none requested
> config:
>
>   NAME        STATE     READ WRITE CKSUM
>   backup      ONLINE       0     0     0
>     da1       ONLINE       0     0     0
>
> errors: No known data errors
>
>   pool: storage
>  state: ONLINE
>   scan: scrub repaired 984K in 11h37m with 0 errors on Mon Jun 16 01:55:48 2014
> config:
>
>   NAME        STATE     READ WRITE CKSUM
>   storage     ONLINE       0     0     0
>     da0       ONLINE       0     0     0
>
> errors: No known data errors
>
>> Running ZFS in a partition or on the entire disk is fine either way. But
>> you have to be consistent. Partitioning a disk and then writing outside
>> of the partition creates errors like the above GEOM one.
>
> Agree. In this instance it wasn't da0/storage, however.
>

You agree, but both of your pools are on the whole disk - da0 and da1
- and not on any partition on that disk. This means that consistently
ZFS will trash the GPT table/labels, because you have told it that it
can write there.

If you GPT partition your disk, your pool should consist of partitions
- da1p1, not da1. You do not need to GPT partition your disk unless
you want to.

Cheers

Tom