ST31000528AS showing as 31.8MB

[Nick_CT]

Hi all,

I have a ST31000528AS fw CC35, comes read and inits fine, reports serial and model number etc, but shows as 31.8MB

In the past I've had many Seagates that report as 0MB, but never one like this. I've tried regenerating translator.

Do you guys have any advice?

[dmarques]

Did you get any error while regenerating translator?

[Nick_CT]

No, no errors there:

Test : Regenerate translator
Result............................................ : Ok

[dmarques]

Can you view the defects lists?

[Nick_CT]

Yes, can view P-list, Alt-list etc all fine. This one is confusing me

[BlackST]

You have PM.

[hddlab]

Why don't you try with SetMax LBA?

[Samo]

Check HPA

[cheadledatarecovery]

32MB? Sounds like and issue with the buffer.

[pcimage]

I assume the jumpers are set correctly and not to 32Gb clip?

[dick]

I assume the jumpers are set correctly and not to 32Gb clip?

I was thinking the same but when I read the thread a second time I realized I had stated 31.8MB So megabytes rather than gigabytes.

[pcimage]

I was thinking that too, but also thinking "typo"

[Samo]

Could it be locked? Momentus XT Hybrid drives show only solid state memory when locked, and suffer pretty same behavior. Show ID and all is fine, only the size is not matching plus terminal is locked .

[Nick_CT]

Thanks for all the replies.

To clarify, it was reading as 31.8MB, not GB. I set the LBA to what it was supposed to be (1 953 525 167) and it then showed the correct capacity of 931GB. I'm baffled as to how, or why, it managed to get itself into that state to begin with? Ok so that fixed the issue of size problems.

The person who the drive belongs to said that when he was using it (in USB external enclosure) it said it wasn't formatted, the usual Windows story. Even though he said he wanted the data, he clicked format...and the drive still wasn't functioning. He then said it started clicking, so he opened it up at work because he wanted to see what was wrong. He said he had a "quick look and closed it again".

To cut a long story short, I had a look and there's a small notch about half way in on the top platter, looks to me like it's suffered some physical damage. I can't see the state of the other platters. There was only one visible piece of (dust?) in the HDA so I got rid of that and anything else that wasn't visible. The filter was clean.

I started imaging the drive (now that it inits and IDs correctly, correct size etc) and it starts off with quite a few unreadable sectors, then after a few minutes it images perfectly for about 5 minutes, then gets to unreadable sectors again, and so the process continues. After a while it hits some serious issues and can't read anything. I've done a heads map and tried some selective imaging.

The person who's drive it is (friend of a work colleague) doesn't actually care about the data so I'm not worried about this case, but it was interesting none the less. I'm not going to pursue this any further. If I wanted to I suppose I could try some donor heads and see if it images any better, but I don't want to risk a good set of heads on this drive.

Here's what the imaging looked like, just for interest's sake.

[Samo]

Have you switched off all the features in the pasp?

[fzabkar]

I'm guessing that your friend's colleague has a Gigabyte motherboard with an Xpress Recovery BIOS. If so, then a bug in the BIOS has incorrectly truncated the drive after writing a backup of itself to a HPA.

See this thread for an explanation:
lost-partition-hitachi-1gb-hdt721010sla360-t15662.html

[Nick_CT]

Very interesting, I wasn't aware of this bug. I'll ask the user if his m/board is indeed the one in question. Good info, thanks Franc. Sneaky BIOS!

[fzabkar]

I've answered similar questions about 50 times in the past 2 years, so it's a common problem. That said, nobody has so far been competent enough to provide the feedback I've asked for, namely where on the drive does the buggy BIOS write its backup? If the copy is written just after the 31.8MB point, then I would expect to see file system corruption. If it written to the end of the drive, then a reverse search should find BIOS related text strings, such as were mentioned in the other thread (eg Award, BIOS). I expect that Xpress Recovery BIOS would need to understand the structure of partition tables, in which case I would expect any copy to be written beyond the partition boundary. If the file system is NTFS, then I would confirm whether the backup boot sector at the end of the partition is still intact.