Maybe confused about AMD64 / i386 compatibility

[Joe Greco]

> On 2009-Jun-13 15:55:29 -0500, Joe Greco <jgreco at ns.sol.net> 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 <rawdev>|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.