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 F1592138373 for ; Tue, 8 Jan 2013 17:43:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 11E8E21C09D; Tue, 8 Jan 2013 17:43:03 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 36C3621C0B7 for ; Tue, 8 Jan 2013 17:41:37 +0000 (UTC) Received: from mail-da0-f41.google.com ([209.85.210.41]:40146) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1TsdB9-001Oqv-3D for gentoo-user@lists.gentoo.org; Wed, 09 Jan 2013 00:41:37 +0700 Received: by mail-da0-f41.google.com with SMTP id e20so297344dak.14 for ; Tue, 08 Jan 2013 09:41:32 -0800 (PST) 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 Received: by 10.68.190.227 with SMTP id gt3mr202528402pbc.5.1357666891996; Tue, 08 Jan 2013 09:41:31 -0800 (PST) Received: by 10.68.248.66 with HTTP; Tue, 8 Jan 2013 09:41:31 -0800 (PST) Received: by 10.68.248.66 with HTTP; Tue, 8 Jan 2013 09:41:31 -0800 (PST) In-Reply-To: <50EC4660.5090208@binarywings.net> References: <50EB2BF7.4040109@binarywings.net> <20130108012016.2f02c68c@khamul.example.com> <50EBCA77.8030603@binarywings.net> <20130108095510.04f84040@khamul.example.com> <50EC4660.5090208@binarywings.net> Date: Wed, 9 Jan 2013 00:41:31 +0700 Message-ID: Subject: Re: [gentoo-user] OT: Fighting bit rot From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=e89a8ff1bf66d21bef04d2ca7469 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Get-Message-Sender-Via: svr-us4.tirtonadi.com: authenticated_id: rileyer+pandu.poluan.info/only user confirmed/virtual account not confirmed X-Archives-Salt: c9635bef-c806-4997-9b86-0e973004fe90 X-Archives-Hash: a08aababc6dcf32cb9f326b61b04268e --e89a8ff1bf66d21bef04d2ca7469 Content-Type: text/plain; charset=UTF-8 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'. I would rather focus my efforts on ensuring that my backups are always restorable, at least until the most recent time of archival. Rgds, -- --e89a8ff1bf66d21bef04d2ca7469 Content-Type: text/html; charset=UTF-8


On Jan 8, 2013 11:20 PM, "Florian Philipp" <lists@binarywings.net> 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'.

I would rather focus my efforts on ensuring that my backups are always restorable, at least until the most recent time of archival.

Rgds,
--

--e89a8ff1bf66d21bef04d2ca7469--