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

[Fabian Keil]

Anders Jensen-Waud <anders at jensenwaud.com> wrote:

> On Sun, Jun 15, 2014 at 05:10:52PM -0400, kpneal at pobox.com wrote:
> > On Sun, Jun 15, 2014 at 03:04:16PM +1000, Anders Jensen-Waud wrote:
> > > Hi all,
> > > 
> > > My main zfs storage pool (named ``storage'') has recently started
> > > displaying a very odd error:
[...]
> > > errors: Permanent errors have been detected in the following files:
> > >         storage:<0x0>
> > 
> > I'm not sure what causes ZFS to lose the filename like this. I'll let
> > someone else comment. I want to say you have a corrupt file in a
> > snapshot, but don't hold me to that.
> > 
> > It looks like you are running ZFS with pools consisting of a single
> > disk. In cases like this if ZFS detects that a file has been corrupted
> > ZFS is unable to do anything to fix it. Run with the option "copies=2"
> > to have two copies of every file if you want ZFS to be able to fix
> > broken files. Of course, this doubles the amount of space you will
> > use, so you have to think about how important your data is to you.
> 
> Thank you for the tip. I didn't know about copies=2, so I will
> definitely consider that option. 
> 
> I am running ZFS on a single disk -- a 1 TB USB drive -- attached to my
> "server" at home. It is not exactly an enterprise server, but it fits
> well for my home purposes, namely file backup from my different
> computers. On a nightly basis I then copy and compress the data sets
> from storage to another USB drive to have a second copy. In this
> instance, the nightly backup script (zfs send/recv based) hadn't run
> properly so I had no backup to recover from. 
> 
> Given that my machine only has 3 GB RAM, I was wondering if the issue
> might be memory related and if I am better off converting the volume
> back to UFS. I am keen to stay on ZFS to benefit from snapshots,
> compression, security etc. Any thoughts?

I doubt that the issue is memory related. BTW, I use single-disk
pools for backups as well and one of my systems only has 2 GB RAM.

My impression is that ZFS's "permanent error" detection is flawed
and may also count (some) temporary errors as permanent.

If the "permanent errors" don't survive scrubbing, I wouldn't
worry about them, especially if no corrupt files are mentioned.

> > You've got something going on here. Did you GPT partition the disk? The
> > zpool status you posted says you built your pools on the entire disk
> > and not inside a partition. But GEOM is saying the disk has been
> > partitioned. GPT stores data at both the beginning and end of the
> > disk. ZFS may have trashed the beginning of the disk but not gotten to
> > the end yet.
> 
> 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  -
> 
> 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? 

As you mentioned being keen on security above, I think it would
make sense to wipe the disk to add geli encryption to the mix [0],
but I doubt that the gpt complaints are related to the "problem".

Fabian

[0] I use zogftw for this: http://www.fabiankeil.de/gehacktes/zogftw/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20140616/db437e0e/attachment.sig>