Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Jan 2012 07:53:46 -0800
From:      Jeremy Chadwick <freebsd@jdc.parodius.com>
To:        Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
Cc:        fs@freebsd.org
Subject:   Re: Unrecognized error on zfs v28
Message-ID:  <20120121155346.GA39342@icarus.home.lan>
In-Reply-To: <alpine.GSO.2.01.1201210906430.15666@freddy.simplesystems.org>
References:  <4F1AC88A.2070603@ukr.net> <alpine.GSO.2.01.1201210906430.15666@freddy.simplesystems.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 |




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120121155346.GA39342>