Hi,

this thread is not your common "please use your crystal ball and gimme some k3wl terminal cmds" thread.
I'd rather like to know the reason why the above happens and whether anyone of you "pros" has ever managed to fix such drive behavior just by some "terminal magic".

I think it was a 7200.10 500GB Seagate drive where I had to go through this, a few years ago.
I had no USB-to-TTL cable, but just a drive which was about to die soon, so I chose to image the whole drive.

I actually DID manage to get my data back, but it took 5 weeks.
Wait a minute...FIVE WEEKS?!?
YES.
I'm not kidding. I used sysresccd which is something for the console folks. However, this method cost me millions of nerves, and I can only recommend it for UBER-PATIENT PEOPLE.

This drive showed a behavior I have never experienced with any drive again.
You'd just use dd on it, using some more advanced commands, and the imaging worked fine ... until 20 minutes later. The image chunk itself (about 12 GB) was fully OK, then I got



Ugh. And now it comes:
I actually had to power-cycle the machine until Linux could recognize the drive again.
I am an advanced user of hdparm and I know most of the cool parameters: --dco-restore, -w (= force hard reset), and its friends.
NOTHING WORKED, even though I had been about sure that at least -w could prevent me from rebooting my PC.

Speaking of which, power-cycling the machine did do the trick, and I could continue where I had left off with the last chunk.
It was a huge work because I had to calculate in sectors and blocks to get chunks (some re-read for safety reasons, so I had some duplicate blocks and had to "glue" them together at the right position), let alone about 50 (!!!) reboots when there were "critical zones" where I could only "catch" 512 MB or even less. I repeat again: after any working chunk that ran into a"Device I/O Error" after the last valid sector read, nothing but a power-cycle could bring the drive "back to life".

Has anyone else experienced such behavior with a drive that "says good-bye" in live operation whenever it feels like it (i. e. on each access of a defective sector) and needs a cold reboot of the PC to get "found" by the system again?
This will even happen with any of those freebie sector checking programs. Supposing the HDD has 10 million sectors, and it accesses sector #7654321, which is defective. Once it accesses this sector, the drive goes all wonky, and sectors #7654322 to #10000000 will result in an ERROR. But in most cases they are not defective!! Because after a power-cycle, (usually) the sectors #DEFECTIVE_SECTOR+N up to last one will read without problems. But not until you did said reboot.

I feel I'm not alone, because to my knowledge, QueTek (the guys that wrote the excellent "FileScavenger") are the only company who wrote a specialized tool that can deal with this kind of drives, called "Disk Recoup". For with drives that behave like this, ANY other recovery tool is powerless. (From personal experience.)

This behaviour can be deliberate on some Seagate drives. You are not alone in seeing this, but it is not related to a defective "track" as you put in the thread title. Since we've had communication problems before, I'll keep my reply quite short to hopefully reduce the chances of misunderstandings.


There are other recovery methods for drives with this behaviour - pros on the forum have reported success using DDI. I've had some success in my lab with other more DIY techniques, but have not had enough examples of drives with that behaviour (since my job is not DR) to refine the technique. In some cases, despite it stressing the drive, automated power-control to the drive was helpful in my investigation (prevents the need to power-cycle the whole PC ), as well as terminal access.

Anyway, my point is just to answer your question about "Has anyone else experienced such behavior" - yes, it's been reported on the forum by other people too.

There is no way you can access single sector, it always involves reading surrounding areas, or not accessible to the user information like embedded servo.
If firmware hangs on certain operation, it usually indicate bugs in firmware triggering such events like "stack overflow" or "access violation" disabling access to some subroutines or "multible exception" errors which are not recoverable without rebooting. Similiar to PC you are perhaps more familiar with.

DeepSpar hardware device...I see.


You can say that again. Drives with this behavior (luckily!) are rare. Well, you could have mine then for testing if you wish. All data is on the safe shore now, so there's nothing to lose any more.



Which brings me to my initial question:
Can such drives - provided you have the required knowlege of advanced (i. e. not "collected-off-internet") terminal commands - be permanently healed from behaving like this? So that you can use them the normal way again?
Or are they "ill for good"?
Besides, how did you perform the "automated power-control"?
One idea (in theory) COULD be to use an external USB interface and add the drive there. (I even had one of these, however these cheapo "Made in China" power supplies included seem to always object against my power installation. They'd always become much too hot and go dead in a few days.) Then, after it goes wonky, unplug USB and replug it, and it ought to come back to life again.

Something like this could do the trick:

http://copyrsoft.com/index.php?option=c ... 59&lang=en

The behaviour which I'm referring to, is not a bug - I think that SAjunky is referring to f/w bugs. All I can say is that what I am describing, is deliberate behaviour (according to Seagate) due to an underlying, internal drive problem. Fix that problem and the "drive dissapearing" behaviour will not then occur. As always, the first challenge is correct diagnosis. Perhaps your case is what SAjunky is describing and not me...


I used USB to interface to an external power controller, which had MOSFET switches and other features, between the PC's PSU and the drive. This was controlled via *nix scripts. The drive itself remained connected via SATA. USB was only used for control/status of the power controller.

So it's a little different to what Cris linked to (which seems to use a serial port on the PC), but the basic objective is similar i.e. to have programatic control of the power supply to the drive.


I've seen people mention that approach on here before. Personally I wouldn't use USB as the data interface to the drive, due to the loss of control (and poor error handling) which results from that. It also needs manual plug/unplug to do the power-cycle. That's why I designed & built my alternative (when I had more spare time than I do now ).

In such case I would check firmware area, backup it, using free tools, then run factory certification tests. I wouldn't care about problem, it would probably gone after tests. All you need is serial to LVTTL convertor and terminal program. And you can continue use hard drive.
Above proposition is not for me, but I wish I could look at it, if you send me a drive.

You never stop learning. Thank you very much. The 2737th use of an Atmel microcontroller. These puppies are really jack-of-all-trades µC's, used in any embedded form that man can imagine. (Off-topic: Now even to get data off ancient media from home computer days.)