Christian Hessmann wrote:
Victor,

Btw, they affect some files referenced by snapshots as
'zpool status -v' suggests:

 >> tank/DVD:<0x9cd> tank/d...@20100222225100:/Memento.m4v
 >> tank/d...@20100222225100:/Payback.m4v
 >> tank/d...@20100222225100:/TheManWhoWasntThere.m4v

In case of OpenSolaris it is not that difficult to work around this bug
without getting rid of files (snapshots referencing them) with errors,
but in I'm not sure how to do the same on FreeBSD.
But you always have option of destroying snapshot indicated above (and may
be more).

I'm still reluctant to reboot the machine, so what I did now was as you
suggested destroy these snapshots (after deleting the files from the
current filesystem, of course).
I'm not so sure the result is good, though:

===============
[r...@camelot /tank/DVD]# zpool status -v tank
  pool: tank
 state: DEGRADED
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
 scrub: resilver completed after 10h42m with 136 errors on Tue Mar  2
07:55:05 2010
config:

        NAME           STATE     READ WRITE CKSUM
        tank           DEGRADED   137     0     0
          raidz1       ONLINE       0     0     0
            ad17p2     ONLINE       0     0     0
            ad18p2     ONLINE       0     0     0
            ad20p2     ONLINE       0     0     0
          raidz1       DEGRADED   326     0     0
            replacing  DEGRADED     0     0     0
              ad16p2   OFFLINE      2  241K     6
              ad4p2    ONLINE       0     0     0  839G resilvered
            ad14p2     ONLINE       0     0     0  5.33G resilvered
            ad15p2     ONLINE     418     0     0  5.33G resilvered

errors: Permanent errors have been detected in the following files:

        tank/DVD:<0x9cd>
        <0x2064>:<0x25a4>
        <0x20ae>:<0x503>
        <0x20ae>:<0x9cd>
===============

Any further information available on this hex messages?

This tells that ZFS can no longer map object numbers from errlog into meaningful names, and this is expected, as you have destroyed them.

Now you need to rerun a scrub.

regards,
victor

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to