From owner-freebsd-stable@FreeBSD.ORG Fri May 30 06:48:59 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3202106566B; Fri, 30 May 2008 06:48:58 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206046210.chello.pl [87.206.46.210]) by mx1.freebsd.org (Postfix) with ESMTP id 5E80E8FC1B; Fri, 30 May 2008 06:48:58 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5AB2045C8C; Fri, 30 May 2008 08:48:56 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 687C74569A; Fri, 30 May 2008 08:48:51 +0200 (CEST) Date: Fri, 30 May 2008 08:48:52 +0200 From: Pawel Jakub Dawidek To: Joe Peterson Message-ID: <20080530064851.GA3596@garage.freebsd.pl> References: <47ACD7D4.5050905@skyrush.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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <47B0A45C.4090909@skyrush.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Analysis of disk file block with ZFS checksum error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2008 06:48:59 -0000 --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--