02-24-2009 02:19 AM
This is a somewhat involved story, so I'll start from the top.
First thing in the morning on Sunday, I turn on my monitors, hit Ctrl+Alt+Del, type in my Windows password, and hit Enter. Before the monitors have a chance to warm up, the system reboots. I would assume this means Windows (XP) bluescreened, but since I never saw it there's no way to know for sure.
The BIOS POST screen comes up, and I immediately notice something is off - the system is taking forever (well, longer than normal, anyway) to POST as it detects the drives. It gets through, though, declares there's no SMART errors, and proceeds. Then Windows doesn't boot.
I immediately go into diagnostic mode. Thinking it's a problem with the RAM, I run Memtest86+. No problems. So I disconnect all my HDs (I have 4) and begin testing them one at a time. I have another desktop with SATA, so I use that to test as well. Eventually, I narrow it down to the ST3400620AS. Computer POSTs as quickly as normal without, and it causes my other desktop to POST slowly as well. Something is up.
I've recovered data from failing drives before. But I can't get anything to boot to an OS (Windows or Linux) with the drive in. I download and burn SystemRecueCD and try that. I'm guessing it works because it doesn't attempt to mount the damaged drive. So I try testdisk and I get nothing. I do fdisk -l, and I can see the partitions on the disk (though it complains they're not sized correctly, but the sizes appear correct). However, the partitions don't appear in /dev like they're supposed to. Finally, I try partimage, and it helpfully offers to mknod the /dev files for me. So now I can try to actually get to the data for the first time.
I don't want to try to mount the partitions, so I use ddrescue to start trying to copy the data. (For the you other Linux/Unix types, ddrescue is basically an enhanced version of dd. It can start/resume copying by keeping a log, try to read all data as quickly as possible while skipping slow/damaged areas, etc.) It seems to be working! But the problem is that I have no way to find out. From what I can tell, it is exceedingly slow - it is having around 30 kB/s, which works out to over a month to recover the entire drive! I've let it work for a day, and it copied over 2GB of data. (partimage wasn't any faster, by the way.)
Here's the thing, though, during that time it did not encounter a single read error. Considering all the other issues, it seems that the drive is just really slow. I am attempting to run SeaTools on it right now, but it just gets to 10% and stops. I ran it on another one of my Seagate drives (one of the infamous 7200.11's, actually) and it worked just fine.
So basically, something is wrong with this drive and I am at my wit's end trying to figure it out. Any help or suggestions would be appreaciated.
02-24-2009 01:22 PM
So I have some performance numbers from hdparm to back me up:
root@sysresccd /root % hdparm -t /dev/sdb
Timing buffered disk reads: 2 MB in 56.59 seconds = 36.19 kB/sec
My other drives average at least 57 MB/s.
root@sysresccd /root % hdparm -t --direct /dev/sdb
Timing O_DIRECT disk reads: 2 MB in 17.39 seconds = 117.75 kB/sec
02-24-2009 04:50 PM
I would think that if SeaTools is having trouble testing that drive, there must be something wrong with it, and you should likely RMA it.
Of course I would recommend trying the drive in another known-working computer first, just to be absolutely sure.
02-24-2009 07:20 PM
Well, there is certainly something wrong with it, and I've had the same problem on two different systems.
However, I need to know if I can fix this somehow, even if it's just temporary so I can get the data off the drive before I RMA it, or if I need to start looking into data recovery services (which, considering the expense, I'd rather not do).