From owner-freebsd-fs@FreeBSD.ORG Sat Jan 21 16:07:04 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AB2A1065670 for ; Sat, 21 Jan 2012 16:07:04 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id C9E3E8FC08 for ; Sat, 21 Jan 2012 16:07:03 +0000 (UTC) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id QE3n1i0021YDfWL53FtoQd; Sat, 21 Jan 2012 15:53:48 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta20.westchester.pa.mail.comcast.net with comcast id QFtn1i00K1t3BNj3gFtofC; Sat, 21 Jan 2012 15:53:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 637C8102C19; Sat, 21 Jan 2012 07:53:46 -0800 (PST) Date: Sat, 21 Jan 2012 07:53:46 -0800 From: Jeremy Chadwick To: Bob Friesenhahn Message-ID: <20120121155346.GA39342@icarus.home.lan> References: <4F1AC88A.2070603@ukr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: fs@freebsd.org Subject: Re: Unrecognized error on zfs v28 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 16:07:04 -0000 On Sat, Jan 21, 2012 at 09:11:40AM -0600, Bob Friesenhahn wrote: > On Sat, 21 Jan 2012, Vladislav V. Prodan wrote: > > >zpool scrub zroot did not help. > >How to deal with such errors? > > A recommendation for how to deal with the problem was provided in > the zpool status "action" text. If you don't have a backup for the > file, then an alternative is to just delete it and hope that you did > not really need it. > > Your pool/filessytem does not include any data redundancy so it is > not able to repair bad data. > > If you had set the zfs filesystem attribute 'copies=2' then zfs > would likely have been able to recover this data, even though you > only have one disk, but more disk space would have been consumed. > ># zpool upgrade zroot > >This system is currently running ZFS pool version 28. > > > > > ># zpool status -v zroot > > pool: zroot > >state: ONLINE > >status: One or more devices has experienced an error resulting in data > > corruption. Applications may be affected. > >action: Restore the file in question if possible. Otherwise restore the > > entire pool from backup. > > see: http://www.sun.com/msg/ZFS-8000-8A > >scan: scrub repaired 0 in 1h54m with 0 errors on Sat Jan 21 00:37:16 2012 > >config: > > > > NAME STATE READ WRITE CKSUM > > zroot ONLINE 0 0 0 > > gpt/disk-system ONLINE 0 0 0 > > > >errors: Permanent errors have been detected in the following files: > > > > /var/imap/vlad11/&BBEEOwQ+BDM-@&BB4EQgRABDAENAQw- > > > ># uname -a > >FreeBSD mary-teresa.XXX 8.2-STABLE FreeBSD 8.2-STABLE #0: Wed Jul 13 > >02:01:02 EEST 2011 root@mary-teresa.XXX:/usr/obj/usr/src/sys/XXX.4 > >amd64 > > > ># zfs get all zroot/var/imap > >NAME PROPERTY VALUE SOURCE > >zroot/var/imap type filesystem - > >zroot/var/imap creation ???? ?????? 1 2:40 2011 - > >zroot/var/imap used 272M - > >zroot/var/imap available 400G - > >zroot/var/imap referenced 206M - > >zroot/var/imap compressratio 2.23x - > >zroot/var/imap mounted yes - > >zroot/var/imap quota none default > >zroot/var/imap reservation none default > >zroot/var/imap recordsize 128K default > >zroot/var/imap mountpoint /var/imap inherited > >from zroot/var > >zroot/var/imap sharenfs off default > >zroot/var/imap checksum fletcher4 inherited > >from zroot > >zroot/var/imap compression gzip local > >zroot/var/imap atime on default > >zroot/var/imap devices on default > >zroot/var/imap exec off local > >zroot/var/imap setuid off local > >zroot/var/imap readonly off default > >zroot/var/imap jailed off default > >zroot/var/imap snapdir hidden default > >zroot/var/imap aclinherit restricted default > >zroot/var/imap canmount on default > >zroot/var/imap xattr off temporary > >zroot/var/imap copies 1 default > >zroot/var/imap version 5 - > >zroot/var/imap utf8only off - > >zroot/var/imap normalization none - > >zroot/var/imap casesensitivity sensitive - > >zroot/var/imap vscan off default > >zroot/var/imap nbmand off default > >zroot/var/imap sharesmb off default > >zroot/var/imap refquota none default > >zroot/var/imap refreservation none default > >zroot/var/imap primarycache all default > >zroot/var/imap secondarycache all default > >zroot/var/imap usedbysnapshots 66,2M - > >zroot/var/imap usedbydataset 206M - > >zroot/var/imap usedbychildren 0 - > >zroot/var/imap usedbyrefreservation 0 - > >zroot/var/imap logbias latency default > >zroot/var/imap dedup off inherited > >from zroot > >zroot/var/imap mlslabel - > >zroot/var/imap sync standard default > >zroot/var/imap refcompressratio 2.21x - Bob, one thing to note is that the R/W/CK counters on his pool as well as his (single) device are all zero. I don't know if the OP did "zpool clear" or not, but if he didn't, then I'm curious how said permanent errors were detected. On Solaris the only time I've seen the above message (specifically that a single-disk vdev experienced loss of files/data) is when there was a non-zero R/W/CK count on either the pool or the device. Sadly the OP did not provide details of what gpt/disk-system is (what hardware's attached to said GPT, etc.), but I'd still expect to see an incremented counter. Also worth noting is that the OP is using compression. That makes me wonder if there may be a bug of some kind there that results in the problem, rather than an actual device I/O error. Finally, the RELENG_8 version he's using is from July 2011. I'm not sure if there have been any fixups to things like this since. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |