Xserve drive replacement

Hi, i did that once a time on recent xserve bi 3Ghz intel of course.
First original HD Hitachi 80Go was mixed with 1To Hitachi.
In other hand, 1To was partitioned and formated/erase first on G5 workstation with macos extended (journaled) for intel boot.
This way, no problems the disk is detected and ready to install os.

( Please sorry me for my bad English spoken... )

I did this yesterday. WD caviar 2TB drive. I changed one jumper on the drive to set sata 150 mode, then put it in an intel xserve carried. Then I booted a Mc OS X Server 10.6 CD, ran disk util, and restored the old boot drive to my new drive and rebooted. Works fine.

Hi,

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.

Cheers
Zach

Oasis, do you mind sharing which Barracuda drives you got? I want to do this to my Xserve G5, but i'm not sure my boss will let me go for the more expensive WD raid drives.

I have to bring this up, having been "enlightened" somewhat over recent days.

We currently have in for data recovery a 64TB Xsan system.

The user was originally sold the system with Promise VTrak servers. And standard hard drives. Three of them have failed in one LUN.

Amazingly, these drives (non-enterprise) were sold with the Xsan.

It is critical that you use Enterprise drives, rather than your average, less costly alternatives. The reason is that a bog-standard drive, on discovering a bad sector, can take up to 60 seconds to reallocate that sector. By that time, the RAID controller has decided the drive has failed, and drops it or marks it bad.

An Enterprise drive reallocates bad sectors in a split second, overcoming this issue, so the RAID controller maintains its healthy status.

That is one of the main reason why server-grade drives are recommended. IT Suppliers should never supply anything but.

Hope this manages to save at least one user from expensive data recovery.

Duncan Clarke
http://www.retrodata.co.uk

That behavior smells more like the drive that lacked some of the SCSI commands, or ran out of spares.

For some controllers and some software, a bad-block revector operation (basically replacing a degraded sector with a spare from a "hidden" pool of spares) can require a SCSI write long command and (if the drive fails to implement that or if the device runs out of spares for the revectoring) there can be a timeout (and SCSI being SCSI, it doesn't even really need a reason for a timeout), and the storage controller then has no choice but to toss the drive.

It's not so much the time for the revectoring (and I'd be floored if a functional revector implementation took anywhere near that much time), but a drive that's forced out because it lacks the necessary features or lacks sufficient capacity for spares, or a controller that tossed the drive because the drive wasn't responding as the controller expected.

Features and just what comprises an "enterprise drive" can be a really slippery concept; try pinning down a storage vendor sometime, and ask them what the actual differences are. It can make for an interesting deer-in-the-headlights discussion.

MrHoffman,

I cannot disagree with everything you say; vendors are notoriously awkward and shy to reveal low-level information about their products.

However, the benefits of using enterprise-grade drives are fairly well-documented.

We have examined the logs of the Xsan we are currently recovering; three failed disks. These logs confirmed that all three disks were dropped because of the discovery of a single bad sector. A single sector taking down an entire production team for a few days. For what you (and I concur) is a slippery concept, I know which drive I would use.

Just to correct one point; you mention "replacing a bad sector" - whereas it does not actually replace the sector; it merely marks the bad sector as such, and reallocates it from a reserved sector. There is a significant difference between the two.

Have a look at the Google and CMU studies around drive errors, if you haven't seen that and should get a chance. Real eye-openers around operational errors, error recovery patterns, MTBF and related topics.

Thanks, yes - I did see that when it was published.

However, many of us in the data recovery business are extremely sceptical about the results Google came up with. I cannot remember the sordid details this far down the line, but one anomaly reared its head in the way temperatures were monitored.

ps: It's usually been the command support that I've seen toss drives. Drives lack that the write long SCSI command; the controller or the drive or the host needs some means of triggering the revectoring; the sector replacement; this beyond the variable size pool of spare sectors I mentioned. Without that write long, there's no (standard) way for a host-initiated revector. (Then there's the discussion of how the sector error got past the EDC and up to the host, but...) Which means either the ARRE or AWRE stuff out in the drive or analogous; delegation of the recovery out to the drive, and a drive inherently doesn't have enough to recover the data while revectoring from a failed sector.)

Data recovery? I feel your pain. I wrote storage-level I/O software and firmware-level stuff for a big vendor; command-level and status-level drive variability was a real headache, and y'all have more vendors and modems and revisions of drives to deal with your recovery environment than I had to deal with for writing and testing the stuff, and we had a shot of fixing the host or the firmware errors.

Hi Duncan,

I had a similar issue with a Promise RAID where 4 disks failed in a row.. (all next to each other). The RAID had been sold with consumer grade Hitatchi drives which according to the distribution company use identical controllers to the more expensive server versions. In the end the problem turned out to be a faulty controller on the Promise rather than the disks, to get round the problem I had to unmount the RAID and via the CLI of the Promise force the disks back online at the suggestion of Promise tech support. The RAID then mounted as expected and continues to run a year later having had the controller swapped for a new one. Good luck with the Xsan.. Sounds like a massive undertaking.

All the best
Beatle

Hi Beatle and particularly MrHoffman

Just looking through this thread again (yes, we successfully recovered the Promise Vtrak) and my previous statement jolted me:

"I cannot disagree with everything you say; vendors are notoriously awkward and shy to reveal low-level information about their products."

I now know the reason for this. The vendors simply DO NOT KNOW the low-level information about their systems.

This has so far been utterly clear with both Infortrend and Promise. They were completely out of their depth with some of the questions we fired at them - and I am talking about top-level support, not a junior.

Something for all users to bear in mind.

Duncan

You're a RAID recovery vendor. Dump the disk blocks and the RAID metadata settings for a working configuration. And connect bus monitors into the configuration, and watch the traffic.

Would you care to translate that, please?