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 4F8321383A7 for ; Wed, 9 Jan 2013 20:55:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1310D21C0BE; Wed, 9 Jan 2013 20:54:39 +0000 (UTC) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A1E0221C074 for ; Wed, 9 Jan 2013 20:53:08 +0000 (UTC) Received: by mail-ee0-f50.google.com with SMTP id b45so1069414eek.23 for ; Wed, 09 Jan 2013 12:53:07 -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=cYw+2KS4CXDFRGF+ilTC00+lG6ZVAC6r1QoqFSv9/kF1oHe3w7TcVisjHFDaxUDMm/ Fv1OqL8IX+ogdhQKXG+/LHwn9u8QKg2npqT44e/NeZWfl7NeqvNFecLTTrCMMRtkWcCU jHRD414gS1krg5ihbxyjG7iWNbEZ5qy08oW0dInwilhyNGsXHpCiqXs3a/0ZeOyiXIge ctY7vgm0iDx+EAnN9OF3TKb+hVymmj16U/Fy5dMWHzC9thn9bnQ/c3obhmknhfgcZcph +0A4+8sJZgVigti1W52kH3VTDeWjPIdoyYPKbo135dOnBmyj02SnYjlTcZig+RvR0TAA FYDw== X-Received: by 10.14.225.194 with SMTP id z42mr186192040eep.22.1357764787280; Wed, 09 Jan 2013 12:53:07 -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 b49sm143750131eem.16.2013.01.09.12.53.05 (version=SSLv3 cipher=OTHER); Wed, 09 Jan 2013 12:53:06 -0800 (PST) Date: Wed, 9 Jan 2013 22:53:00 +0200 From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: OT: Fighting bit rot Message-ID: <20130109225300.5e4b9661@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> <20130109013726.4016dda2@khamul.example.com> <20130109103151.428615f7@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: 449ae5f7-3ee7-49a2-8aca-c4c1aa4b3f8f X-Archives-Hash: c99d354444872a037a1bd786028628b6 On Wed, 9 Jan 2013 14:48:33 +0000 (UTC) Grant Edwards wrote: > On 2013-01-09, Alan McKinnon 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