From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-user+bounces-144270-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id 2E9EA138350
	for <garchives@archives.gentoo.org>; Mon,  7 Jan 2013 23:26:01 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 8FDEA21C056;
	Mon,  7 Jan 2013 23:25:45 +0000 (UTC)
Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id D3CFD21C056
	for <gentoo-user@lists.gentoo.org>; Mon,  7 Jan 2013 23:24:39 +0000 (UTC)
Received: by mail-wg0-f48.google.com with SMTP id dt10so10321266wgb.27
        for <gentoo-user@lists.gentoo.org>; Mon, 07 Jan 2013 15:24:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=x-received:date:from:to:subject:message-id:in-reply-to:references
         :organization:x-mailer:mime-version:content-type
         :content-transfer-encoding;
        bh=fNEEbMuTMLL8M85EBoFIva35JYhUxy2dwRrRo+GZSEE=;
        b=MHCQodhVLQwTOJ50g46Gis4oNvecH+M5AhalJK5k4+WObVQP+wc/jVi/8OZRkRiUlb
         3GxYeWldSY16m+XBR4p45m+qE43w1ACiSsTNvOKYAgwo/g/TAVSuEZDRMktHPqHyd0A/
         ajVtAzRHqXDmU9QRnHk6Fqn4NzFMm2QymQCxd5ej9l6Eg4VNNyHw1WsPtV0dGyu0zcFs
         8B8K+czUUr+H8WkVEUCzzZ7WiTpOB16+uGW46t2o7lgoCe4WcrF4AA3w9EMPN1IpjUS7
         hRWnbfiqyDdwcsKEHDhBVcK3CEmFy8/Uc45y1pZHI9bXCxVJiIEHVH9m2Q4nV0NVswgL
         rwGQ==
X-Received: by 10.194.86.40 with SMTP id m8mr98166479wjz.24.1357601078551;
        Mon, 07 Jan 2013 15:24:38 -0800 (PST)
Received: from khamul.example.com (196-215-209-117.dynamic.isadsl.co.za. [196.215.209.117])
        by mx.google.com with ESMTPS id g2sm15971400wiy.0.2013.01.07.15.24.36
        (version=SSLv3 cipher=OTHER);
        Mon, 07 Jan 2013 15:24:37 -0800 (PST)
Date: Tue, 8 Jan 2013 01:20:16 +0200
From: Alan McKinnon <alan.mckinnon@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] OT: Fighting bit rot
Message-ID: <20130108012016.2f02c68c@khamul.example.com>
In-Reply-To: <50EB2BF7.4040109@binarywings.net>
References: <50EB2BF7.4040109@binarywings.net>
Organization: Internet Solutions
X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.14; x86_64-pc-linux-gnu)
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
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-Archives-Salt: 9d5c28e7-32b5-4860-a005-ad2f4bc2dff7
X-Archives-Hash: dbb1d6c1bc91e4b9e628f22d624d999d

On Mon, 07 Jan 2013 21:11:35 +0100
Florian Philipp <lists@binarywings.net> wrote:

> Hi list!
> 
> I have a use case where I am seriously concerned about bit rot [1]
> and I thought it might be a good idea to start looking for it in my
> own private stuff, too.
> 
> Solving the problem is easy enough:
> - Record checksums and timestamps for each file
> - Check and update records via cronjob
> - If checksum changed but timestamp didn't, notify user
> - Let user restore from backup
> 
> However, I haven't found any application in portage for this task.
> Now, the implementation is easy enough but I'm wondering why it
> hasn't been done. Or do I just look for the wrong thing? The only
> suitable thing seems to be app-admin/tripwire but that application
> also looks like overkill.
> 
> [1] http://en.wikipedia.org/wiki/Bit_rot
> 
> Regards,
> Florian Philipp
> 

You are using a very peculiar definition of bitrot.

"bits" do not "rot", they are not apples in a barrel. Bitrot usually
refers to code that goes unmaintained and no longer works in the system
it was installed. What definition are you using?

If you mean crummy code that goes unmaintained, then keep systems up to
date and report bugs.

If you mean disk file corruption, then doing it file by file is a
colossal waste of time IMNSHO. You likely have >1,000,000 files. Are
you really going to md5sum each one daily? Really?

This is a filesystem task, not a cronjab task. Use a filesystem that
does proper checksumming. ZFS does it, but that is of course somewhat
problematic on Linux. Check out the others, it will be something modern
you need, like ext4 maybe or btrfs

-- 
Alan McKinnon
alan.mckinnon@gmail.com