Hi all,

I have an issue with my barracuda 7200.11. This is the drive with the SD15 firmware that was susceptible to busy states, LBA0 problems, etc

that being said, I have something totally different going on. The file system is NTFS. booting it as a slave on my win7 machine shows the drive as being listed, but with 0 capacity. if I launch the drive management console, it lists the correct capacity.

here comes the strangeness:

I use some recovery utilities that boot off a CD. it has a mini-XP environment with diagnostic tools, etc. if I boot into this with the suspect drive slaved off, I can see all my files and begin to start copying over to my other drive. The data actually copies fine from this point. However, this only works for about 10 minutes before I start receiving I/O errors and other weird anomalies. if I run chkdsk after this has occured, it will get random errors such as "the file system is RAW", etc.

My thought process is that the drive is overheating somehow after it has been running for a period of time. anyone have any thoughts on this? it seems pretty warm to the touch

I have a RS232->TTL converter that I just tested the loopback on, so connecting into the drive will be possible if someone more knowledgeable than myself deems it necessary

help, please!

Where exactly are you looking and seeing that capacity. Did you mean to say that you were seeing that listed for the relevant drive letter's "Total Size" in "My Computer"? If so, then that is the filesystem capacity and suggests that the filesystem itself has problems / corruption. That's not a surprising consequence, since you seem to be having interruptions to I/O, based on your description. It does complicate your recovery, as you cannot assume that copying of files will be correct, from a corrupted filesystem.


If you see that underneath the "Disk0" (or "Disk1" etc.) label, then the drive itself is reporting the correct capacity. Is that where you were seeing the correct capacity shown?


I suspect this is not a time "thing", but that you're starting to hit unreadable sectors. You mention "wierd anomalies" - do you find that you have to power-cycle the drive before you can start to read from it again, after these "anomalies" start?

If your data is important, you need to consider whether or not you really want to take the risks of DIY (which you have already started), since the drive might deteriorate (thereby making pro recovery more difficult / expensive) during your attempts. Or whether the importance of the data makes the use of a pro's services more appropriate.

One relatively low-risk thing you can do, to attempt to confirm my suspicion of bad blocks, is to collect the full raw SMART data (e.g. using HDDScan) and supply that in your reply.

P.S. Yes, the terminal output could also be used to confirm the "bad block" diagnosis, but the SMART data is probably easier for you IMHO.

correct. I am seeing the 0 size capacity when right clicking the drive in my computer. if I then go to the drive management console in windows, it will show the correct capacity.

the files that I have managed to copy before receiving I/O errors (in my virtual bootCD environment) are fine.

I will get the SMART data and reply with it here. I did run the SMART test via the seagate tools and it came back fine. the Short DST test did fail, however

what could be causing these I/O interruptions?

Understood, so my related comments above re: filesystem corruption apply.


You were lucky, as I explained re: corrupted filesystems.


Yikes! So this confirms a hardware fault with the disk, as I suspected. It's likely that unreadable sectors (pending or already reallocated) will be seen in the SMART data. Please confirm that Seatools does show what is called "raw" values for each SMART attribute. If it does not, then it is not suitable for supplying the data I requested and HDDScan should be used (from hddscan.com).


As I explained in my previous comment, I suspect unreadable sectors are the cause (common with 7200.11 drives, in my experience) - the SMART data will show whether this is true or not. The failed Short DST certainly confirms some kind of fault with the drive.

You didn't answer my question about whether or not you needed to power-cycle the drive / system, once the "anomalies" & I/O errors started, before any more files were readable during your testing. Did you miss that question? Do you understand what I mean?

If your data on the drive is of limited value, and if you are happy to take DIY risks and not to involve a DR company, then the typical approach for a drive which could deteriorate at any point (like this one), would be to try to clone the whole drive ASAP to a drive of the same (or larger) capacity (e.g. using Linux ddrescue or other programs specifically designed for cloning). However if the data does have value, then before things deteriorate, a DR company with dedicated hardware cloning equipment has a better chance to get a more complete image of a faulty drive, than a software-only DIY approach.

nicad, check your pm.