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 A7885138376 for ; Tue, 8 Jan 2013 19:55:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 29D0721C0F9; Tue, 8 Jan 2013 19:55:36 +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 7E28D21C006 for ; Tue, 8 Jan 2013 19:54:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 8B58233D90D for ; Tue, 8 Jan 2013 19:54:04 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.286 X-Spam-Level: X-Spam-Status: No, score=-1.286 tagged_above=-999 required=5.5 tests=[AWL=-2.487, 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 aydu__5eHvYk for ; Tue, 8 Jan 2013 19:53:58 +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 A5E5A33C394 for ; Tue, 8 Jan 2013 19:53:57 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TsfFR-00082n-Hk for gentoo-user@gentoo.org; Tue, 08 Jan 2013 20:54:09 +0100 Received: from dsl.comtrol.com ([64.122.56.22]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Jan 2013 20:54:09 +0100 Received: from grant.b.edwards by dsl.comtrol.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Jan 2013 20:54:09 +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: Tue, 8 Jan 2013 19:53:41 +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> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dsl.comtrol.com User-Agent: slrn/pre1.0.0-18 (Linux) 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 X-Archives-Salt: a622e8dc-6d03-472f-a3fc-0332a608be1e X-Archives-Hash: e8b17855c8abcdace68d081456ebf8e1 On 2013-01-08, Pandu Poluan wrote: > On Jan 8, 2013 11:20 PM, "Florian Philipp" wrote: >> > > -- snip -- > >> >> Hmm, good idea, albeit similar to the `md5sum -c`. Either tool leaves >> you with the problem of distinguishing between legitimate changes (i.e. >> a user wrote to the file) and decay. >> >> When you have completely static content, md5sum, rsync and friends are >> sufficient. But if you have content that changes from time to time, the >> number of false-positives would be too high. In this case, I think you >> could easily distinguish by comparing both file content and time stamps. >> >> Now, that of course introduces the problem that decay could occur in the >> same time frame as a legitimate change, thus masking the decay. To >> reduce this risk, you have to reduce the checking interval. >> >> Regards, >> Florian Philipp > > IMO, we're all barking up the wrong tree here... > > Before a file's content can change without user involvement, bit rot must > first get through the checksum (CRC?) of the hard disk itself. There will > be no 'gradual degradation of data', just 'catastrophic data loss'. When a hard drive starts to fail, you don't unknowingly get back "rotten" data with some bits flipped. You get either a "seek error" or "read error", and no data at all. IIRC, the same is true for attempts to read a failing CD. However, if you've got failing RAM that doesn't have hardware ECC, that often appears as corrupted data in files. If a bit gets erroneously flippped in a RAM page that's being used to cache file data, and that page is marked as dirty, then the erroneous bits will get written back to disk just like the rest of them. -- Grant Edwards grant.b.edwards Yow! ... he dominates the at DECADENT SUBWAY SCENE. gmail.com