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 41EF4138390 for ; Wed, 9 Jan 2013 08:34:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 293BB21C026; Wed, 9 Jan 2013 08:34:12 +0000 (UTC) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 68CF721C070 for ; Wed, 9 Jan 2013 08:31:59 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id d13so555918eaa.21 for ; Wed, 09 Jan 2013 00:31:58 -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=r5Cbp2bfeihGIjJChoZhEkRE7lSBU23WmhYUzQ8Sfzc=; b=VbcpMXDxz6c+T6RULkcT7ARRNWWhPtTczJG+7i2d25vsc/Dyi559em4HdZ2iSvPvIF aeiVKf8l1vdUc/dItwXl6rpgVXJ9J75FMUWbhWzzV9p9e3d4PyxEtK97vBIeLsj6z3Ng rRSoDeP0VonO9NWWdqpfAORpqnzCri18+ybGI9Vmrb8bjui04cLjRVD1DMszYPKcoIXu iI5SetXzKu67UHqS28DNioaxzxgn1kZok7nFCx37ke87uAP2WJOjoAK/9ukD6lRrqpLq BzFLXoaXkiKDPNUIDY+V8jm4kr+vIyPj7cqHMBwwNamNE4NwHTPrjrc/vo9/y6sJHEcS vNSQ== X-Received: by 10.14.194.195 with SMTP id m43mr180714692een.44.1357720318119; Wed, 09 Jan 2013 00:31:58 -0800 (PST) Received: from khamul.example.com (196-215-69-201.dynamic.isadsl.co.za. [196.215.69.201]) by mx.google.com with ESMTPS id f49sm140207971eep.12.2013.01.09.00.31.54 (version=SSLv3 cipher=OTHER); Wed, 09 Jan 2013 00:31:56 -0800 (PST) Date: Wed, 9 Jan 2013 10:31:51 +0200 From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: OT: Fighting bit rot Message-ID: <20130109103151.428615f7@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> 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: 32d97c63-c0a8-43bc-aade-7bcda48d6a1e X-Archives-Hash: 6266ebc95ad8eb14c3534ccfe16293a7 On Wed, 9 Jan 2013 02:47:07 +0000 (UTC) Grant Edwards wrote: > > 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. > > I don't understand. If you're worried about media failure, what good > does checksumming at the file level do when failing media produces > seek/read errors rather than erroneous data? When the media fails, > there is no data to checksum. Not file level - it's filesystem level. It checksums filesystem blocks. And we are not talking about failing media either, we are talking about media corruption. You appear to have conflated them. The data on a medium can corrupt, and it can corrupt silently for a long time. At some point it may deteriorate to where it passes a cusp and then you will get your first visible sign - read failure. You did not see anything that happened prior as it was silent. -- Alan McKinnon alan.mckinnon@gmail.com