Seagate Barracuda 7200rpm SATA
320gig by chance? There seems to be a bad batch of these that made it out there a couple of years ago... Ive got one in the range of those that have had problem drives so Ive been hesitant to use it for anything serious...
Ive never had any problems before or after that period (which the dates escape me) in fact I have no trouble with our later models we use...
That would be the Cuda 11 series. It's a firmware related issue and the 500GB and under drives are particularly hard hit. I used to help recover the drives but the 500GB units proved to be a hit and miss affair.
The 1TB generally worked fine (and continued to do so for quite a long time) but the 500GB units I fixed (it's a temporary fix by clearing the test logs area) usually only lasted 2 to 3 additional power cycles and become unfixable after that. AFAIK, the 750GB and above models had a new firmware that resolves the issue but there never were any for the lower capacity models.
Each drive's firmware contains a drive testing algorithm built-in for factory QC/ reliability testing. Before testing for each batch, the drives concerned are loaded with settings to conduct the self-test and write out the logs to a specific area on the drives. These logs cannot be overwritten by subsequent tests and have to be cleared manually (automatically on the test machines which interface directly to the microcontroller).
The problem came when, somehow, the drives sent for production did not have the self-tests disabled so each time the drive powered up, it performs the test and writes the log. When the log area is filled, the drive shutsdown operations (this is a safety measure for testing so that logs won't get discarded during QC phase). To recover the drive with data intact, one needed to directly interface with the MCU on the drive; there are 4 pins on the back of each Seagate drive for serial communications and power - TX/ RX/ V+/ GND.
You'd need to temporarily disconnect the motor (can be achieved by sliding a plastic piece between the contacts) because the drive would conduct tests upon spin-up and lock-up immediately.
Once a link is established with the MCU, you needed to tell it to ramp down the motor and connect the board back to the motor. Then disable the tests, clear the log area and ramp the motor back on. This gives several extra power cycles during which you can: Recover the data, flash the firmware to a fixed firmware etc.
I know this for a fact since I was an IT consultant with one of their sub-contractors building QC equipment racks for them and I encountered the exact same issue with the refurbished drives used during our equipment testing (we were manually running tests and the logs clearing issue wasn't made clear to us until all our test drives locked up and everyone started pointing fingers). After we were informed of the issue, the drives had the logs cleared and we were back in business.
I'm just glad that we made an exit before the 11th series was out wreaking havoc. Otherwise, I'd be sure that they would have been pointing fingers our way (the engineer for the project was quite hostile towards us since he wanted another sub-con handling the project but we won it).
pfSense Forum
