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 E43BE13837E for ; Tue, 8 Jan 2013 23:43:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 82F21E05F2; Tue, 8 Jan 2013 23:43:29 +0000 (UTC) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id F23E021C022 for ; Tue, 8 Jan 2013 23:41:50 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id t11so747762wey.26 for ; Tue, 08 Jan 2013 15:41:49 -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=TIP2LteNrMnYSd8+U21Vq+Mc3JaVhzRpRTm0Ho9zmEE=; b=TKLC7r9tHe7SR6mjfDrUkyyjLPv0q4KRy1P62DL5sXSfqYbYYxvPbceXS37ZtlGrl8 TzKiokEcTt2C3I7Uoe63QmEf11oAcuG8Pb02kR11RXf1szJ9xfcavMUK4EXucAeX3fqH siBOiqiKfD3xi7icltV4ZqBg7g/Lrdme1FkO9UxShaPovZH89WSBGdu1KshVyRekucBh 2WhMxo0a+fD3fX5ROWeaNfiR4hlXwrzEau/yZNaXvGJyIOZxLghTfW9YRFvzL7HABn3w sey+PfTVXh9XF5Vn8vhBPLGzzRkpR2cOom6ZdJjtY4tqOyOiRz6vyqp2/AiHsuIobkOI ftHg== X-Received: by 10.180.14.2 with SMTP id l2mr17850003wic.2.1357688509692; Tue, 08 Jan 2013 15:41:49 -0800 (PST) Received: from khamul.example.com (196-215-2-44.dynamic.isadsl.co.za. [196.215.2.44]) by mx.google.com with ESMTPS id df2sm1390300wib.0.2013.01.08.15.41.47 (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 08 Jan 2013 15:41:48 -0800 (PST) Date: Wed, 9 Jan 2013 01:37:26 +0200 From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: OT: Fighting bit rot Message-ID: <20130109013726.4016dda2@khamul.example.com> In-Reply-To: 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> Organization: Internet Solutions X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.14; x86_64-pc-linux-gnu) 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-Archives-Salt: 4551a45e-ca6f-45b8-83f2-d203f0154591 X-Archives-Hash: c19c0464156a1a802b7cc0924a244de3 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, 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. Pity about the license incompatibility, it's a great fs. -- Alan McKinnon alan.mckinnon@gmail.com