Analysis of disk file block with ZFS checksum error

Pawel Jakub Dawidek pjd at FreeBSD.org
Fri May 30 06:48:59 UTC 2008


On Mon, Feb 11, 2008 at 12:39:08PM -0700, Joe Peterson wrote:
> Gavin Atkinson wrote:
> > Are the datestamps (Thu Jan 24 23:20:58 2008) found within the corrupt
> > block before or after the datestamp of the file it was found within?
> > i.e. was the corrupt block on the disk before or after the mp3 was
> > written there?
> 
> Hi Gavin, those dated are later than the original copy (I do not have
> the file timestamps to prove this, but according to my email record, I
> am pretty sure of this).  So the corrupt block is later than the
> original write.
> 
> If this is the case, I assume that the block got written, by mistake,
> into the middle of the mp3 file.  Someone else suggested that it could
> be caused by a bad transfer block number or bad drive command (corrupted
> on the way to the drive, since these are not checksummed in the
> hardware).  If the block went to the wrong place, AND if it was a HW
> glitch, I suppose the best ZFS could then do is retry the write (if its
> failure was even detected - still not sure if ZFS does a re-check of the
> disk data checksum after the disk write), not knowing until the later
> scrub that the block had corrupted a file.

ZFS doesn't verify checksum after write, it would be pointless for two
reasons:
1. The read will come most likely from disk cache and not from the
   stable storage.
2. This would kill performance.

ZFS test checksum only on read. What you observe is either a misdirected
read/write (you asked to read/write sector X, but the data was read
from or wrote to sector Y) or a phantom write (you asked to write, but
the data never reach the disk, so you have old data there).

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080530/47b1ef84/attachment.pgp


More information about the freebsd-stable mailing list