From owner-freebsd-stable@FreeBSD.ORG Tue Aug 12 04:04:49 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 C7BA71065673 for ; Tue, 12 Aug 2008 04:04:49 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id 9AB408FC1B for ; Tue, 12 Aug 2008 04:04:49 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: by mx1.synetsystems.com (Postfix, from userid 66) id 711B6B62; Mon, 11 Aug 2008 23:45:07 -0400 (EDT) Received: from rmtodd by servalan.servalan.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1KSkkb-000J1X-8c; Mon, 11 Aug 2008 22:40:49 -0500 To: Jeremy Chadwick References: <20080810175934.X2427@borg> <20080811065822.GA81972@voi.aagh.net> <20080811130555.GA25024@eos.sc1.parodius.com> From: Richard Todd Date: Mon, 11 Aug 2008 13:53:03 -0500 In-Reply-To: (Jeremy Chadwick's message of "Mon, 11 Aug 2008 06:05:55 -0700") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: ICRC's 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: Tue, 12 Aug 2008 04:04:49 -0000 Jeremy Chadwick writes: > If Larry was using UFS, he'd also see the above errors from the kernel. > FreeBSD reports the CRC errors reported by the ATA device, ZFS reports > the said data as corrupted during scrubbing or standard usage (hence the > CKSUM field in 'zpool status'), and ZFS also *repairs* the corrupted > data. I can't explain how the repair works, but it's one of the many > features of the filesystem. I believe journalling filesystems (e.g. Um, not exactly. It's one of the features of the filesystem when you're running on a ZFS pool which is mirrored or raidz. If your ZFS pool is not mirrored or raidz-ed, checksum errors *will* be unrepairable and should show up as read errors to the application. AFAIK, the "repair" is just ZFS either finding a good copy of the block from the other half of the mirror (if mirrored) or reconstructing the missing block thru parity (if raidz-ed) and rewriting it.