> On 2009-Jun-13 15:55:29 -0500, Joe Greco <jgr...@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. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
