Date: Mon, 16 Jun 2014 08:11:42 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Anders Jensen-Waud <anders@jensenwaud.com> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS pool permanent error question -- errors: Permanent errors have been detected in the following files: storage: <0x0> Message-ID: <alpine.BSF.2.11.1406160742570.5783@wonkity.com> In-Reply-To: <20140616024942.GA13697@koodekoo.local> References: <CALvn0yiiBJRWvA0QWmQMaC=k8ZwEmmDe6vuySQT=o%2BdA3wAyEA@mail.gmail.com> <20140615211052.GA63247@neutralgood.org> <20140616024942.GA13697@koodekoo.local>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.11.1406160742570.5783>