From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 14 00:44:40 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE32F1065670 for ; Sun, 14 Jun 2009 00:44:40 +0000 (UTC) (envelope-from jgreco@aurora.sol.net) Received: from mail2.sol.net (mail2.sol.net [206.55.64.73]) by mx1.freebsd.org (Postfix) with ESMTP id 909278FC0A for ; Sun, 14 Jun 2009 00:44:40 +0000 (UTC) (envelope-from jgreco@aurora.sol.net) Received: from aurora.sol.net (aurora.sol.net [206.55.65.130]) by mail2.sol.net (8.14.1/8.14.1/SNNS-1.04) with ESMTP id n5E0icvB078426; Sat, 13 Jun 2009 19:44:39 -0500 (CDT) Received: (from jgreco@localhost) by aurora.sol.net (8.12.8p1/8.12.9/Submit) id n5E0iqYN072978; Sat, 13 Jun 2009 19:44:52 -0500 (CDT) From: Joe Greco Message-Id: <200906140044.n5E0iqYN072978@aurora.sol.net> To: peterjeremy@optushome.com.au (Peter Jeremy) Date: Sat, 13 Jun 2009 19:44:52 -0500 (CDT) In-Reply-To: <20090613230749.GA73896@server.vk2pj.dyndns.org> from "Peter Jeremy" at Jun 14, 2009 09:07:50 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Maybe confused about AMD64 / i386 compatibility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 00:44:41 -0000 > On 2009-Jun-13 15:55:29 -0500, Joe Greco wrote: > >Adding a SIL3112A gives us the SATA. > > These are known to cause data corruption (check the archives). I > wouldn't trust anything that has passed through a SIL chip without > independent validation. I already said it had been validated. gunzip|restore tvf was happy with the entire thing. A FreeBSD 6.1R/amd64 box is currently happily RESTORING the SIL-written gzip'ed file using a USB-to-SATA adaptor, TOO, so all evidence is that the on-disk file data is sane. I checked for general data corruption at the device level with md5 and posted a brief summary of those results; the results are that everything appears to be reading the disk blocks sanely. That was why I posted such a long summary of what had been done; I felt certain someone would try to claim dodgy hardware. The SIL does seem to spit off lots of spurious interrupts, and does not work at all with non-native SATA drives; being a backup system, I had already stress tested various combinations of things, and I'm aware of the various PC hardware deficiencies. So, let me re-summarize and simplify the issue to clarify: I have a large (~400GB) file on a large (~1.5TB) filesystem created on 7.2R-i386. 7.2R-i386 reads the file correctly (via SIL or via USB-to-SATA). 6.1R-amd64 reads the file correctly (via USB-to-SATA). 7.1R-amd64 does NOT read the file correctly (via USB-to-SATA). In all of the above cases, the underlying hardware and device drivers appear to be returning the same data, as evidenced by dd |md5 of random portions of the disk. In other words, the SIL is not in the equation. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.