Thanks, now I understand how the "CKSUM" is counted. Both fmdump and
scrub indicate that there is one error in the .vdi file.
Is there a way to enforce zfs to accept the new checksum of the file?
Since it is a hard drive image file I rather let the guest OS of the VM
handle that corruption (using 'scandsk /F' and 'sfc /scannow').
As it is now, the zfs errors (ensuing from the corruption) make the VM
freeze so I can't let this checksum difference remain. There must be a
way to "clear" this corruption somehow.
I tried to copy the file but cp cannot copy the entire file, it halts
barely halfway through and returns an I/O error.
The fmdump errors look like this btw:
--------------------
cksum_expected = 0x2489fee7aaa6 ... ... (the other checksums match)
cksum_actual = 0x2489fee7aaa2 ... ... ...
cksum_algorithm = fletcher4
--------------------
On 2012-02-20 05:51, George Wilson wrote:
Take a look at 'fmdump -eV' as it should give you more information about the
each of the checksum errors.
- George
On Feb 19, 2012, at 3:23 PM, Richard Lowe wrote:
Vague recollection that the pool level is errors that weren't
recovered, so possibly two of them on the device were ditto'd
metadata? (I'm very unsure on both counts).
Otherwise, as Chris said, iostat is particularly difficult to trust.
No matter what the error (even if, indeed, the drive or transport)
there's no guarantee (or in my bitter experience even likelyhood) of
formal errors occurring to go with the data being bad.
-- Rich
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
