From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-144351-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 899321383A7
for <garchives@archives.gentoo.org>; Wed, 9 Jan 2013 20:55:00 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 1267621C0B9;
Wed, 9 Jan 2013 20:54:40 +0000 (UTC)
Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 37FF821C043
for <gentoo-user@lists.gentoo.org>; Wed, 9 Jan 2013 20:53:01 +0000 (UTC)
Received: by mail-we0-f182.google.com with SMTP id u54so1304473wey.13
for <gentoo-user@lists.gentoo.org>; Wed, 09 Jan 2013 12:53:00 -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=3O+Oyr5XWcXdXp4JL/J3XM6vqEAU+eG0MWXHm6SYj3s=;
b=koEr+G67VrmPNTqJGBYNL3jiDoBCcUToKoZF45Ccw7CpeCMDeSGIB4JVPhVjXFTnOp
AWekZzaE+GaaL/U53J9Ft0+8MJRV3iLhl1R8ow2HBC0mTYi9Jk4sCwpEh7PROQ0GUKls
0W9+NBzGZTAE/9TDpvyGrjqBQ+9eD77i4vE8XRqvnW2gvfU4SE5DJttwlCUI50lDByY/
8CRrHK+C8tBnPjsW5ROa67TZTyI93d2jAcloy4W/mY2Mo4Fv+dTWWGeSNPsNIAMZZqvt
yJBqXX6PLS8ibLo2O3PTITdD5tTUfCqJgmdN17HtKsQrPGZX0V0/PPWtqvwVcMGEP4Iz
6GFA==
X-Received: by 10.181.13.195 with SMTP id fa3mr5457950wid.8.1357764780808;
Wed, 09 Jan 2013 12:53:00 -0800 (PST)
Received: from khamul.example.com (196-210-100-42.dynamic.isadsl.co.za. [196.210.100.42])
by mx.google.com with ESMTPS id ew4sm5997787wid.11.2013.01.09.12.52.57
(version=SSLv3 cipher=OTHER);
Wed, 09 Jan 2013 12:52:59 -0800 (PST)
Date: Wed, 9 Jan 2013 22:52:15 +0200
From: Alan McKinnon <alan.mckinnon@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: OT: Fighting bit rot
Message-ID: <20130109225215.26eca51b@khamul.example.com>
In-Reply-To: <kck001$9pc$1@ger.gmane.org>
References: <50EB2BF7.4040109@binarywings.net>
<20130108012016.2f02c68c@khamul.example.com>
<50EBCA77.8030603@binarywings.net>
<20130108095510.04f84040@khamul.example.com>
<50EC4660.5090208@binarywings.net>
<CAA2qdGUn8pf4WKsKugFeY20aXrciyQiwpigGVs+5xkjW4hbBsQ@mail.gmail.com>
<kchtg5$dku$1@ger.gmane.org>
<20130108234504.08c19c9c@khamul.example.com>
<kci5pj$rt5$1@ger.gmane.org>
<20130109013726.4016dda2@khamul.example.com>
<kcilna$du$1@ger.gmane.org>
<20130109103151.428615f7@khamul.example.com>
<kck001$9pc$1@ger.gmane.org>
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: 37c72b6f-433f-406c-bdf9-c69b56d5da11
X-Archives-Hash: ee26c4cac9ccf136c56443a34650828a
On Wed, 9 Jan 2013 14:48:33 +0000 (UTC)
Grant Edwards <grant.b.edwards@gmail.com> wrote:
> On 2013-01-09, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> > On Wed, 9 Jan 2013 02:47:07 +0000 (UTC)
>
> > The data on a medium can corrupt, and it can corrupt silently for a
> > long time.
>
> And I'm saying I've never seen that happen.
>
> So you're saying that the data on a medium can corrupt without being
> detected by the block encodings and CRCs used by the disk controller?
No, I'm not saying that *at*all*
I've been saying all along that data which you never go near can
corrupt silently while you are not using it. When you do eventually get
around to reading it, the electronics will do what they are designed to
do and properly detect a problem that already happened.
>
> > At some point it may deteriorate to where it passes a cusp
> > and then you will get your first visible sign
>
> No, the first visible sign in the scenario you're describing would be
> a read returning erroneous data.
That's what I said. The first VISIBLE sign is an error. You want to
catch it before then.
Analogy time: A murderer plans to do Grant. By observing Grant and only
observing Grant, the first visible sign of an issue is the death of
Grant. Obviously this is sub-optimum and we should be looking at a few
more things than just Grant in order to preserve Grant.
>
> > - read failure. You did not see anything that happened prior as it
> > was silent.
>
> If a read successfully returns correct data, how is it "silent"?
I never used those words and never said "successfully returns correct
data". At best I said something equivalent to "If a read returns".
The point I'm trying hard to make is that all our fancy hardware merely
gives an *apparency* of reliable results that are totally right or
totally wrong. It looks that way because the IT industry spent much
time creating wrappers and APIs to give that effect. Under the covers
where the actual storage happens it is not like that, and errors can
happen. They are rare.
Lucky for us, these days we have precision machinery and clever
mathematics that reduce the problem vastly. I know in my own case the
electronics offer a reliability that far exceeds what I need so I can
afford to ignore rare problems. Other people have different needs.
--
Alan McKinnon
alan.mckinnon@gmail.com