^ I want to dampen the joy a little bit.
It seems to depend on the connected drives' type/brand or connection type.
My successful tests have been with 2 naked Toshiba drives, connected through a SATA to eSATA cable.
Whereas today I tried connecting a
My Book Home Edition WD10000H1Q-00 (2x FW800, 1x USB 2.0, 1x eSATA) via and eSATA to eSATA cable. The drive mounts fine, but as I tried copying a folder from the WD MyBook to my MacBookPro 15" Late 2006 (MA609LL), Finder aborted with error -36 (ioErr, according to
Classic Mac OS error table), which seems to still have the same meaning for OSX as checking Console.app showed the according kernel error message "disk1s2: I/O error", matching exactly the MyBook disk number 1, and partition (=Volume) nr 2, from which I attempted to copy.
The kernel had also thrown "SATA WARNING: IDENTIFY DEVICE checksum not implemented." right after I had plugged in the WD MyBook, before I attempted the copy operation. This warning was always reproducible with the eSATA connected WD MyBook, and never occurred with the SATA —> eSATA connected Toshiba drives!
Querying the WD MyBook through eSATA with smartctl also works only partially, only showing the section "General SMART Values", but not the full info, and the output ends with: "Warning: device does not support Error Logging", which certainly is not true, because through USB, which technically uses
SCSI passthrough, the full SMART query works fine!
The reason for this particular SATA failure may be:
- the drive type/brand (WD10EACS-00ZJB0),
- the enclosure (MyBook Studio WD10000H1Q-00) 's firmware (?)
- the connection — eSATA vs SATA cable, or my only eSATA cable being faulty
I try to rule out some causes:
Ad 1) Maybe. But I can neither do tests with more eSATA drives to verify that others work nor more naked SATA drives to falsify that all SATA drives work fine as I don't have those at hand. Experiences anyone?
Ad 3)
Wikipedia concerning eSATA
It uses a more robust connector, longer shielded cables, and stricter (but backward-compatible) electrical standards. The protocol and logical signaling (link/transport layers and above) are identical to internal SATA.
Most likely not the reason, except it's the unlikely case of a "backward compatibility" issue, or more probably, maybe the used eSATA cable is faulty, but I cannot test that as I have no other one at hand currently.
Ad 2)
The enclosures are not the source of the Kernel Panic and data corruption problems. I had these happen even with a ESATA-to-SATA cable directly connected to the drive.
But the knowledge base of WDC suggests that certain PCI cards are incompatible with certain enclosures (respectively their firmware):
And more generic SATA with OS X issues, as we discussed them here:
The question is wether the enclosure just passes through the "SATA data stream" (sorry if this is a technically incorrect term), or does in transcode/repackage some things? For USB and Firewire the enclosure obviously has to alter the data stream into the according protocol stream, but what in the case of SATA?
So against Timur's statement, enclosure chipset incompatibility is an officially documented reason. (See sources above).
UPDATE: I updated one of my 2 WD MyBook's firmware from 10.28 to 10.34. Did not help. SMART queries still only pass partially. Writing to the WD MyBook works quite well, wrote ~10GB to it at about 40-50 MB/s, but as sonn as I try to read from it I only get a data rate of 2 MB/s or less, and soon after that a kernel I/O error. Seems to be an unfixable incompatibility, at least under the driver in Mac OS X 10.6. Will only connect that enclosure through USB2 (25-30 MB/s) or FW800 (30-35 MB/s). They are slower but reliable.
UPDATE 2: CONCLUSION: The eSATA ExpressCard AKE BC338 should work fine with all naked SATA disks, and better not be used with certain eSATA enclosures (chipset: Oxford Semiconductor OXU931DS).