Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 May 2008 08:48:52 +0200
From:      Pawel Jakub Dawidek <pjd@FreeBSD.org>
To:        Joe Peterson <joe@skyrush.com>
Cc:        freebsd-fs@freebsd.org, freebsd-stable@freebsd.org
Subject:   Re: Analysis of disk file block with ZFS checksum error
Message-ID:  <20080530064851.GA3596@garage.freebsd.pl>
In-Reply-To: <47B0A45C.4090909@skyrush.com>
References:  <47ACD7D4.5050905@skyrush.com> <D6B0BBFB-D6DB-4DE1-9094-8EA69710A10C@apple.com> <47ACDE82.1050100@skyrush.com> <20080208173517.rdtobnxqg4g004c4@www.wolves.k12.mo.us> <47ACF0AE.3040802@skyrush.com> <1202747953.27277.7.camel@buffy.york.ac.uk> <47B0A45C.4090909@skyrush.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--Q68bSM7Ycu6FN28Q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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?
>=20
> 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.
>=20
> 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).

--=20
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

--Q68bSM7Ycu6FN28Q
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFIP6NTForvXbEpPzQRAquWAKCV3zdQRV84Rgo2wOVqcTEpT+Sq+QCg5vsx
dysO0Htb8e2R/zqPIzAJzGU=
=GOYO
-----END PGP SIGNATURE-----

--Q68bSM7Ycu6FN28Q--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080530064851.GA3596>