Dag-Erling Smørgrav wrote:
quoted text
> There is now way to "read the bad data" since an unrecoverable checksum
> error means that ZFS has no idea which of the multiple version of the
> affected block is the right one.

Nope, no mirror, no RAIDZ - just one partition.  But as far as I know, there
were no read errors, just a checksum error.  I've also done a couple of
surface scans of the drive, and no problems.  So all I can imagine is that
either data got "changed" on the disk (due to who know what), or the metadata
got messed up (either hardware or some SW bug).

I'd like to figure out what ZFS thinks the bytes in the file really are and
why they are showing as a checksum error.  So, since I only have one copy
(i.e. no RAID/mirror), then I should be able to tell ZFS to "go ahead and read
the bytes, not stopping when it hits the checksum mismatch).  Then I could do
an analysis of the data, compared to what the file should contain.

I assume I can hack the ZFS source to "disable" stopping on the checksum
problem, but I figured there might be some debug mode that would let me do
this without delving into the code.

quoted text
> (I assume this was a raidz pool; if not, imagine Nelson Muntz from the
> Simpsons yelling "ha ha!" at you)

Ah, don't worry, I have backups (I'm just playing around with ZFS at the
moment...  :)

quoted text
> My advice is to use 'dd conv=noerror' with a sufficiently small block
> size to recover what parts you can.

I haven't lost anything, so no need to do that.  I just want to see what's up
with this particular ZFS issue.  If it's a bug, at least I could submit it to Sun.

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