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

View: New views
2 Messages — Rating Filter:   Alert me  

Parent Message unknown Re: [zfs-discuss] ZFS non-zero checksum and permanent error with deleted file

by Steven Samuel Cole :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Thank you very much for your reply! :-)

Trevor Pretty schrieb:

> Steven
>
> I had a similar problem back in 2006 when I was first playing with ZFS.
> Jeff Bronwick sent me this. It may (or not) help. I'm not sure if the
> number is still the inode. If it is a please let zfs-discuss know.
>
>
>> > I've a non-mirrored zfs file systems which shows the status below. I saw
>> > the thread in the archives about working this out but it looks like ZFS
>> > messages have changed. How do I find out what file(s) this is?
>> > [...]
>> > errors: The following persistent errors have been detected:
>> >
>> >           DATASET  OBJECT  RANGE
>> >           LOCAL    28905   3262251008-3262382080
>>  
>
> I realize this is a bit lame, but currently the answer is:
>
> find /LOCAL -mount -inum 28905
>
> And yes, we do indeed plan to automate this.   ;-)
>
> Jeff

Did your output come from a Solaris system ?

I couldn't find anything about a -mount parameter in the find man page,
what does it do ?

[user@host ~]$ sudo zpool status -v zpool01
   ...
errors: Permanent errors have been detected in the following files:

         zpool01:<0x3736a>


[user@host ~]$ sudo find /mnt/zpool01/ -inum 3736a
find: -inum: 3736a: illegal trailing character
[user@host ~]$ sudo find /mnt/zpool01/ -inum 0x3736a
find: -inum: 0x3736a: illegal trailing character

Apparently, the -inum parameter needs a decimal number:

[user@host ~]$ sudo find /mnt/zpool01/ -inum 226154
[user@host ~]$

How could find ever find anything ? The file at that inode as deleted
after all. And even if it did find anything, what would I do with the
result ?
_______________________________________________
freebsd-questions@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@..."

Parent Message unknown Re: [zfs-discuss] ZFS non-zero checksum and permanent error with deleted file

by Steven Samuel Cole :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@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@..., http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

_______________________________________________
freebsd-questions@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@..."