[zfs-discuss] ZFS non-zero checksum and permanent error with deleted file

[Steven Samuel Cole]

Bob Friesenhahn schrieb:
> On Thu, 5 Nov 2009, Steven Samuel Cole wrote:
> 
>>> Definitely do
>>>
>>>   zpool scrub zpool01
>>>
>>> to see if there is any other decay.
>>
>> I have done that prior to getting the status, several times actually, 
>> tried to indicate that in my OP. IIRC, all checksums are zero after 
>> clearing; after scrubbing, the total checksum goes back up to 4. The 
>> error is not cleared, though.
> 
> Strange.  I do recall that there was one OpenSolaris development release 
> which did produce spurious checksum errors which looked weird like 
> that.  Hopefully you are not using that particular release.

I am using ZFS as it comes with the official FreeBSD 7.2 64bit, no 
patches, no dev releases, all binary out of the box, nothing self-built. 
IIRC, that's ZFS version 6.

> Your 'zpool status' output did not indicate that a scrub was done.

You are correct, my mistake. I reproduced the 3 zpool command lines in 
my OP from memory. I have gone through many clear/scrub/status, 
export/import, wash/rinse/repeat cycles now, the 'last scrub' info must 
have gone lost in one of them. A scrub on that pool takes ~8 hours, so I 
refrained from running it again just for demonstration purposes.

Hmmm. Just as I want to double-check, I get this:

[user at host ~]$ sudo zpool history
History for 'zpool01':
2008-05-31.22:16:22 zpool create -m /mnt/zpool01 zpool01 raidz1 ad12 
ad14 ad16 ad18
2008-12-28.15:06:54 zpool import zpool01
2008-12-28.18:37:42 zpool export zpool01
2008-12-28.18:51:39 zpool import zpool01
2009-01-05.17:31:51 zpool export zpool01
2009-01-05.19:55:27 zpool import -d /dev/disk/by-id zpool01
2009-08-25.00:50:31 zpool clear zpool01
Assertion failed: ((null)), function nvlist_lookup_string(records[i], 
ZPOOL_HIST_CMD, &cmdstr) == 0, file 
/usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/zpool/zpool_main.c, 
line 3338.
Abort trap: 6 (core dumped)

Sigh. Maybe I should take that as another indication that something is 
just not right and I should rebuild the pool, afterwise there'll always 
be that nagging thought if my data is actually safe...

> 
> Bob
> -- 
> Bob Friesenhahn
> bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/