ST3500320AS Seagate drive disappears

[helpless]

Hi, everyone!
Problem #1: (smaller problem) drive has a corrupted partition table. After painfully slow booting and aborting windows checkdisk attempt, all 4 partitions appear in windows explorer, but only 1 partitions shows its size and it is correct. Disk manager shows the partitions correctly but believes they are empty (not empty). It is impossible to explore partitions, because explorer doesn't respond and also get "Windows - Delayed Write Failed ..." message.
Problem #2: (bigger problem) After a few minutes usage, drive disappears, and only reappears after system shutdown and startup. If I start with MHDD from Hiren boot cd, scanning of first 8% goes well, and all of a sudden, I get nothing but ABRT errors.
History: Drive's BSY error was fixed (by common internet fix, done by me; no need to comment on this ), new SD1A firmware was flashed. SMART values gradually worsened. Current state below.
F3 1>N5
Att
Num Flgs normlzd worst raw
1 000F 61 4E 0000000089AFE2
3 0003 5E 5D 00000000000000
4 0032 62 62 00000000000966
5 0033 2B 2B 00000000000490
7 000F 4D 3C 000000036F0E71
9 0032 56 56 00000000003352
A 0013 64 62 00000000000179
C 0032 61 25 00000000000F47
B8 0032 64 64 00000000000000
BB 0032 1 1 00000000001A18
BC 0032 64 59 00001A001A0037
BD 003A 64 64 00000000000000
BE 0022 4E 36 00000016160016
C2 0022 16 2E 00000400000016
C3 001A 2E 16 0000000089AFE2
C5 0012 64 64 0000000000036F
C6 0010 64 64 0000000000036F
C7 003E C8 BD 0000000000014C

Connecting to terminal I get:
Rst 0x20M
(P) SATA Reset

My question is: can anyone point to the possible cause of these symptoms? Most important is to fix problem #2, in order to clone the drive. Not planning to pay $$$, if cannot fix, RMA it to manufacturer and lose data. By the way, there was an opportunity to have a free backup of the RMA-d drives - having BSY error - by Seagate, does anyone know if it is still in force and it applies to my case?

If there's nothing that can be done, I'll try to clone with ddrescue, hope it has some feature to resume cloning after a complete system shutdown. If you know this soft well, I'd be glad to hear how to set it up with the right parameters correctly.

----------------
No matter how much I agree with those advices, that: "Take it to a pro!" and "There is no 1 button fix!" , I would like to hear something different (in meaning). Thank you in advance!

[Vulcan]

I don't have time to write a long reply, and you are asking several questions (and need some corrections ) but here are a couple of comments. If you don't like these comments or disagree, then just ignore them. I'm hoping they will help other people in future, not just you. If you are lucky, other members who have more time than me, might give you more answers:

drive has a corrupted partition table.

No, it doesn't (or at least your description does not give any evidence of that). The symptoms you describe are another effect of your "problem #2". Corruption in the partition table would give different symptoms (remember what is actually in the partition table, and what is elsewhere and must be readable).

I'll try to clone with ddrescue, hope it has some feature to resume cloning after a complete system shutdown.

Please spend some time learning ddrescue, if you decide to use it (e.g. first practice cloning some other, unimportant disks). Also read the online manual. Then your uncertainty will become clear. It is possible to make your situation much worse, if you use the wrong command line parameters with ddrescue. Investigate the use of the logfile, and remember that it should be written to a persistent filesystem.

Good luck!

[helpless]

Vulcan
Thanks for your your input. I wish you had more experience in DR - I know from your posts, that it is not your main task - and could help beginners even better (I am not complaining, just feel you are not the type, who fears to share some knowledge in contrary to many others).
But back to the case it would be useful to know, what causes problem #2. You've met many such cases (so I read), could you ever find out what had happened to these drives?
I will give ddrescue a try, as you suggested. I found an interisting example in ddrescue manual, seems it is tailored for my case:

While rescuing the whole drive /dev/hda to /dev/hdb, /dev/hda stops responding and disappears from /dev.

ddrescue -f -n /dev/hda /dev/hdb logfile <-- /dev/hda fails here
(restart /dev/hda or reboot computer as many times as needed)
ddrescue -f -n -A /dev/hda /dev/hdb logfile
ddrescue -d -f -r3 /dev/hda /dev/hdb logfile

Does ddrescue copy to an image file, or is it just an option?

Spildit
I don't know how an update could have failed, if everything finished without problem.
I scanned starting from the error part (after 8%) but there were no errors, so I stopped scanning before new errors could have come (maybe around 16%).
But the interesting thing I discovered is that although I interrupted at LBA 84,740,834, in the upper right part it shows 3,276,957 and also in the right side it keeps repeating the same number. There was no error at LBA 3,276,957

What did you input in terminal to fix the problem ?

I have no clue what to input, what I read across the board that I shouldn't play. I tried "dot" command, result is:
F3 T>
Current R/W User LBA 00000000 LLL CHS 000000.0.0000 PLP CHS 000000.0.0000
R/W Status 1 R/W Error 00000080 Ready
What do you suggest to do? You also had a drive with that message. Could you fix it?

You might have one of several problems, by what you stated.

Hope it's nothing personal and refers to the drive!

You will need to investigate it further, try to hook the drive to terminal and do some testing.

Ok, what should I test?

[Vulcan]

Just briefly, as I only have 5 mins...

I will give ddrescue a try, as you suggested.

To be clear - I did not suggest that you "give ddrescue a try". You said you were going to try ddrescue "If there's nothing that can be done" and I just offered some advice, if you chose to use it. There are risks with your plan, and it has to be clearly your choice (and your responsibility) whether you continue with your plan, but since the data is not worth enough for you to consider using professional DR services (although they would likely not be too expensive at this point), I understand you may want to try something, even if you lose all your data.

I found an interisting example in ddrescue manual, seems it is tailored for my case

Unless you are using IDE-SATA adapters or an old Linux kernel, those exact device names won't match your system. It's much more likely yours will use /dev/sd[x]. This is one of the many reasons why I suggested (previously) that you do some practicing first.

That series of ddrescue commands may not be optimal for your drive with that exact behaviour. Instead I would consider appropriate use of the -E (or -e or -T) options, with the problem drive attached via SATA, to abort quickly after the drive stops responding. However many different approaches are possible.

Does ddrescue copy to an image file, or is it just an option?

It's an option - your choice, depending on exactly what you want to do.

I'll just say that I wouldn't do further scanning with MHDD, because you are risking "diagnosing the drive to death" without actually recovering anything. Your data, your risk, your choice. Good luck!

[Vulcan]

Your drive have a damaged translation table or sub-system, judging by the look of the MHDD picture.

Personally I have a different hypothesis, based on the same MHDD picture - with translation problems, I don't expect to see the UNC first (notice the "x" from MHDD). The live terminal output when the problem starts (or displaying the drive's internal log of the recent errors afterwards) may also be helpful in confirming or disproving any diagnosis.

I can think of a few different approaches but one imperfect test for translation issues (whilst still risking "diagnosing the drive to death") is to try to read (or clone) backwards on the drive, from the high LBA backwards, without doing any reads forwards first. If any reads of the high LBAs are successful, it tends to suggest this is not a translation issue. I agree that applying the previous terminal commands (whatever they were) may have changed or worsened the situation.

[Vulcan]

Judging by the attached photo the drive didn't read past 3,276,957

Indeed, but in my experience on recent Seagate drives that doesn't necessarily mean that all those LBAs are unreadable e.g. when reading them backwards.

[dobrevjetser]

Non resident glist has been erased and now problem is 10 times worse.
Internet fix without proper diagnosis!
Now only a pro can fix and it will NOT be cheap.

Dobre

[Vulcan]

now problem is 10 times worse.

Of course if the OP has made things worse via the terminal (but has not given us the details about) then I've wasted my time giving any comments about ddrescue, so I'll stop here.

Edited to add: @helpless, it may assist people who are trying to help you, if you list the exact commands which you entered via the terminal. Even better would be if you kept a text log of your commands and the drive's responses, while you were doing that process as you applied the "fix", and can supply that log.

[dobrevjetser]

Nrg list starts from 7200.11 family !

[dobrevjetser]

All of them as far as i know.

Dobre

[dobrevjetser]

Good luck !

Dobre

[northwind]

I agree with Dobre.
If Glist was cleared without NRG being taken into account then it has to be manually reconstructed. A real PITA.

[dick]

Hi, i am finding this thread interesting so I just wondered why the NRG has to be taken into consideration. I have used the 'internet fix' on several occasions and never took the NRG into account and the fix worked flawlessly. If this time the fix hasn't worked would that be because there are bad sectors in the SA?
I also have to admit on one occasion I did have difficulty accessing and copying the data so I used a simple work around that got the data. I set the bios parameters to CHS instead of LBA or auto for the source drive. The original poster might well try himself just in case it works for him as well.

[helpless]

Wow! Never hoped to attract so many people!

After fixing bsy error drive worked well. It was more than a year ago. Is it not enough proof that fix completed successfully? Could it effect drive's behaviour not immediately, but years later? I can't remember if any other experiments were executed on the drive. I remember though a SMART erase on one of my drives, but I can't recall which drive (maybe this, maybe not). The drive was used by my children, and I know HD Sentinel reported worse and worse health. I also overwrote first few megabytes by a 'reverse' cloning (target and source were replaced by mistake), but that was corrected - and I think (maybe wrongly) it doesn't seem to effect the problem.

A new test picture scanning from LBA 100.000.000. is below. It seems, that every time MHDD encounters a bad sector - if it really does that - , it triggers something to send the drive offline - or so I think. From that point on, no software will recognize it. Resetting the comp doesn't help, drive is only detected again if power-cycled. And despite the fact that 3,276,957 was not even scanned, it is blamed repeatedly.

[dick]

After fixing bsy error drive worked well. It was more than a year ago.

I do wish you had mentioned that in the first post.

So what are you after? The data or a repair?

If it is a repair then you are wasting your time!

If you want the data I think you might have to consult a pro.

RMA looks the way to go.

[Vulcan]

@helpless,

It seems, that every time MHDD encounters a bad sector

... actually it is every time the drive attempts to read such sectors - to be clear, it doesn't have to be MHDD which is involved ...

it triggers something to send the drive offline - or so I think. From that point on, no software will recognize it. Resetting the comp doesn't help, drive is only detected again if power-cycled.

Yes, the MHDD display (with the UNC that I highlighted before) and your description both match a known behaviour for a specific type of Seagate drive fault. Anyway, I've already given my (amateur) suggestions (since this is exactly the behaviour which I thought the drive had). Good luck.

@dick,

Agreed about getting the whole story at the beginning being better.

[Vulcan]

On the time you should have tossed the drive to the bin, when you recovered your data.

Although you & I disagree on the interpretations of the MHDD output, I certainly agree with this comment! Personally I would never trust a drive after any serious problem (although I keep some in my lab, to try to simulate "real life" problems in our arrays ).

[helpless]

Sorry for not being clear about the drive's history, I didn't know that it had such a great importance, it was just a short list of events that happened in the (remote) past. (Same as you visit your new doc and tell about previous diseases. )
I want to recover as much data as possible. I opened this topic is to collect hints by more experienced fellows of what might ease this task, in order to minimize risk and maximize data quantity. I plan to use ddrescue and begin with copying one of the last 2 partitions and see what I get. If that will prove useless, I will follow some advice, which will be experimenting in terminal, hopefully given by some good soul, if there is one out. Yes, I ask for free advice. All risks are born by me of course.
Don't plan to use the drive, it is covered by warranty, once data is (hopefully) backed up, goes back to Seagate.

[helpless]

I need some more votes on translator problem.
The question is:
Does a drive with a translator error go offline and come back to a working state after a power-cycle only?
Can anyone confirm Spildit's assumption?

[dobrevjetser]

Ofcourse its not NRG list. If the author had been clear about the history i would not have mentionned this. Again an example how important it is to tell everything in order to do a proper diagnosis.

I need some more votes on translator problem.
The question is:
Does a drive with a translator error go offline and come back to a working state after a power-cycle only?
Can anyone confirm Spildit's assumption?

There are seagates with these symptoms, yes.