From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 74EA4138383 for ; Wed, 9 Jan 2013 02:49:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9008021C12D; Wed, 9 Jan 2013 02:49:09 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 09ABA21C03C for ; Wed, 9 Jan 2013 02:47:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 3C47533DA2E for ; Wed, 9 Jan 2013 02:47:33 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: 0.292 X-Spam-Level: X-Spam-Status: No, score=0.292 tagged_above=-999 required=5.5 tests=[AWL=-0.909, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hA_uIt-XENBu for ; Wed, 9 Jan 2013 02:47:27 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 9B35333DA28 for ; Wed, 9 Jan 2013 02:47:27 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TslhX-0006iZ-IT for gentoo-user@gentoo.org; Wed, 09 Jan 2013 03:47:35 +0100 Received: from c-24-118-110-103.hsd1.mn.comcast.net ([24.118.110.103]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Jan 2013 03:47:35 +0100 Received: from grant.b.edwards by c-24-118-110-103.hsd1.mn.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Jan 2013 03:47:35 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Grant Edwards Subject: [gentoo-user] Re: OT: Fighting bit rot Date: Wed, 9 Jan 2013 02:47:07 +0000 (UTC) Message-ID: References: <50EB2BF7.4040109@binarywings.net> <20130108012016.2f02c68c@khamul.example.com> <50EBCA77.8030603@binarywings.net> <20130108095510.04f84040@khamul.example.com> <50EC4660.5090208@binarywings.net> <20130108234504.08c19c9c@khamul.example.com> <20130109013726.4016dda2@khamul.example.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-24-118-110-103.hsd1.mn.comcast.net User-Agent: slrn/0.9.9p1 (Linux) X-Archives-Salt: a58a54d2-3855-46f0-8e48-2837f40bc922 X-Archives-Hash: 4894f94f40a5f59d6129d5c202db8f1c On 2013-01-08, Alan McKinnon wrote: > On Tue, 8 Jan 2013 22:15:15 +0000 (UTC) > Grant Edwards wrote: > >> IMO, having backup data _is_ very valuable, but regularly reading >> files and comparing them to backup copies isn't a useful way to detect >> failing media. > > He doesn't suggest you compare the live data to a backup. He suggests > you compare the current checksum to the last known (presumed or > verified as good) checksum, My point is that comparing the read data with is a waste of time if you're worried about detecting media failure. In my expierence, you don't _get_ erroneous data from failing media. You get seek/read failures. > and if they are different then deal with it. "deal with it" likely > involves a restore after some kind of verify process. > > I agree that comparing current data with a backup is pretty pointless - > you don't know which is the bad one if they differ. > > ZFS is designed to deal with this problem by checksumming fs blocks > continually; it does this at the filesystem level, not at the disk > firmware level. I don't understand. If you're worried about media failure, what good does checksumming at the file level do when failing media produces seek/read errors rather than erroneous data? When the media fails, there is no data to checksum. -- Grant