Analysis of disk file block with ZFS checksum error

[Julian Elischer]

Joe Peterson wrote:
> Chris Dillon wrote:
>> That is a chunk of a Mozilla Mork-format database.  Perhaps the  
>> Firefox URL history or address book from Thunderbird.
> 
> Interesting (thanks to all who recognized Mork).  I do use Firefox and
> Thunderbird, so it's feasible, but how the heck would a piece of one of
> those files find its way into 1/2 of a ZFS block in one of my mp3 files?
>    I wonder if it could have been done on write when the file was copied
> to the ZFS pool (maybe some write-caching issue?), but I thought ZFS
> would have verified the block after write.  It seems unlikely that it
> would g

it could be an old file..
what kind of disks?
I had a scenario where 3ware controllers were just failing to write to
a drive in the array, so old data showed through.

it was possible by looking to see where the boundary between good and 
bad was, to identify the culprit..

the filesystem and the partitions and the raids all were on different
alignments so teh only part of the system that had a boundary that 
aligned with the bad data was the physical stripes laid down by the 
controller.  It was 64k stripes and 64k data missing, exactly on
stripe boundaries. Due to the fact that FreeBSD had partitioned the 
drive staring at 63 blocks in, nothing else aligned with the problem.


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