Date: Mon, 11 Aug 2008 13:53:03 -0500 From: Richard Todd <rmtodd@ichotolot.servalan.com> To: Jeremy Chadwick <koitsu@FreeBSD.org> Cc: freebsd-stable@freebsd.org Subject: Re: ICRC's Message-ID: <x74p5r4c4w.fsf@ichotolot.servalan.com> In-Reply-To: <servalan.mailinglist.fbsd-stable/20080811130555.GA25024@eos.sc1.parodius.com> (Jeremy Chadwick's message of "Mon, 11 Aug 2008 06:05:55 -0700") References: <20080810175934.X2427@borg> <20080811065822.GA81972@voi.aagh.net> <20080811130555.GA25024@eos.sc1.parodius.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeremy Chadwick <koitsu@FreeBSD.org> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?x74p5r4c4w.fsf>