Xserve drive replacement

You've posted a link indicating that you're associated with a firm that does data recovery, or did I misinterpret that?

Accordingly, I'd expect a data recovery firm to have access to hardware mechanisms that allow I/O traffic to be monitored (SAS or SATA for the newer stuff, FC or USB if you're working with that, and SCSI and IDE for the older stuff), and typically using a device known as a bus analyzer. The bus traffic typically uses known command and response formats determined by the T10 and T13 folks and by the implementors, and potentially with some extensions for device-specific additions or variations.

These (bus-specific) analyzers are standard practice when integrating a device, and I'd assume that a data recovery firm would likely be using similar techniques to investigate the device interfaces and the controller metadata in the absence of available documentation on the controller and the storage.

This is how you integrate and test a new peripheral device, after all, and (in conjunction with the metadata and the volume structures) how you'd figure out what happened to a semi-functional semi-failed device. This is also part of the underpinnings of the vendor costs of a supported device; why hardware support has value.

You've posted a link indicating that you're associated with a firm that does data recovery, or did I misinterpret that?

No - not at all. We are involved in data recovery and also R&D relating thereto.

Data recovery companies do not generally have any such monitoring equipment; we are here to provide data recovery services and not necessarily to repair faulty equipment beyond what is strictly necessary in order to extract the data.

I fully accept that hardware support is critical - especially in a SAN or Xsan environment. But the perception that the manufacturers have all the facts is, as we have discovered, not true at all - hence my previous post.


Duncan

I have an expectation that organizations in this area would have these devices available directly or on call; whether the tasks involved either integration, testing, qualification or recovery.

An organization working with peripherals can operate without these devices but (and having performed just that task on occasion), you really lack a good view into the device and the bus activities. Doing this in software is really ugly (been there!), and (on various platforms) the host I/O driver stack can get in the way of the integration. Or of the data recovery.

One device I've monitored was working sans errors, though (when we used the analyzer) fully two thirds of the bus traffic was error recovery processing. That was some impressively-crafted recovery software in the host, too. And that host software wasn't tossing any of the blizzard of device errors up to the user.) That error traffic led to some further investigation and a tear-down, which lead to the realization there had been a component change and a batch of bad hardware.

Irrespective of the qualification, having device-level access is how you can often pull data out of a storage device, too; even if your local host controllers and software can't particularly deal with the device interface.

"Just as an aside on this topic, I recently changed out all 3 Drives in our G5 Xserve and replaced then with RD RE4 2Tb drives (model WD2003FYYS). No jumpering required, and haven't skipped a beat."

I just replaced two of the drives in an XServe G5 2.0ghz with 2 WD RE4 2TB drives as well (WD2003FYYS)

All the drives were originally 80GB ADM, then 750GB.

The 2TB drives did not want to come up. Setting jumpers for 1.5gb PHY seemed to help, the drives then came up in the middle bay, didn't seem to come up in the 3rd bay.

I formatted for Apple Partition Map (PPC) and then the drives are coming up in both bays.

System Profiler reports SMART = No

Reconfirmed removing the jumper means the drive wouldn't come up (orange led)

As you might imagine, this is an old system now, and its still going strong. Drives are now part of a Mirror, and we'll see how they go.

System just passed a reboot.