Date: Mon, 16 Jun 2014 09:39:28 +0200 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: 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: <20140616093928.1b96f24b@fabiankeil.de> 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
[-- Attachment #1 --] Anders Jensen-Waud <anders@jensenwaud.com> wrote: > On Sun, Jun 15, 2014 at 05:10:52PM -0400, kpneal@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/ [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlOenzMACgkQBYqIVf93VJ14AwCgl4C8314mGJE8BVfOlNeGo894 adgAoIUE/+DHFSJau7R1h4A3DY67IWgw =15fk -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140616093928.1b96f24b>