TiVo Community
TiVo Community
TiVo Community
Go Back   TiVo Community > Underground Playground > TiVo Underground
TiVo Community
Reply
Forum Jump
 
Thread Tools
Old 06-23-2012, 12:59 PM   #1
The Great Inert
Registered User
 
Join Date: Jun 2012
Posts: 24
Unexpected dd_rescue Marathon

Hello, everyone.

Before I start, I want to publicly and sincerely thank HomeUser, Unitron, and Guy Kuo for providing almost immediate, very patient advice to me over the last few days that I have tried to recover my drive. You are indeed princes among men, and if I could buy you all a drink of your choice I would. I'm new to this forum, but can honestly say that I know it is a better place for their presence.

I've started a new topic as opposed to keeping this question in my ongoing thread because I'm hoping to get as many confirmations of my suspicions as I can. Here's my problem: I have a dying 1tb drive that I'm attempting to clone to a new 1tb drive. I'm using dd_rescue (the command I used was: dd_rescue -A -v /dev/sda /dev/sdb) to do the clone. The program has been running for almost 21 hours now and seems to be stuck in a loop. The only screens I get are ones referencing bad sectors, but the program has done nothing to indicate that it's actually transferred any files from one drive to another.

I did some research and came across this site

http://paulski.com/zpages.php?id=1913#addendum

Which provides a helpful screenshot of what (I think) the program should display when it's actually copying files. According to the site, I should be seeing something like this.



I have not seen this message, at all, for more than a second or two in the last 20+ hours. All I have seen is screen after screen of bad sector information. The message does pop up after a bad sector is detected, but again, there's no information at all to indicate that files are being copied.

The only thing I can think of to explain this behavior is that the PCB on my source drive is damaged, enough so that it will not allow dd_rescue to actually transfer files.

With that in mind, here are my questions.

1. Does dd_rescue attempt to ignore all of the bad sectors on a drive before it actually starts to transfer files from one drive to another?

2. Assuming that I actually have this many bad sectors on the drive (i.e., that the PCB board isn't damaged and just shooting out errors because it's damaged,) is it normal for bad sector detection to take this long?

3. Is there a limit to the number of bad sectors a drive can have before it's actually unrecoverable?

4. Is there a point at which it would be reasonable for me to terminate dd_rescue altogether, and attempt to clone the drive through other means? (Most likely I'd use MFStools>MFScopy or the JMFS boot disk I found here yesterday.)

(In case anyone is interested, I'll upload video of what's going on later this afternoon.)

Special thanks again to HomeUser, Unitron, and Guy Kuo for all of your help these last few days, and many many thanks in advance for any new insights gathered through this post.

Last edited by The Great Inert : 06-23-2012 at 01:05 PM.
The Great Inert is offline   Reply With Quote
Old 06-25-2012, 04:20 AM   #2
unitron
Registered User
 
unitron's Avatar
 
Join Date: Apr 2006
Location: semi-coastal NC
Posts: 13,418
Quote:
Originally Posted by The Great Inert View Post
Hello, everyone.

Before I start, I want to publicly and sincerely thank HomeUser, Unitron, and Guy Kuo for providing almost immediate, very patient advice to me over the last few days that I have tried to recover my drive. You are indeed princes among men, and if I could buy you all a drink of your choice I would. I'm new to this forum, but can honestly say that I know it is a better place for their presence.

I've started a new topic as opposed to keeping this question in my ongoing thread because I'm hoping to get as many confirmations of my suspicions as I can. Here's my problem: I have a dying 1tb drive that I'm attempting to clone to a new 1tb drive. I'm using dd_rescue (the command I used was: dd_rescue -A -v /dev/sda /dev/sdb) to do the clone. The program has been running for almost 21 hours now and seems to be stuck in a loop. The only screens I get are ones referencing bad sectors, but the program has done nothing to indicate that it's actually transferred any files from one drive to another.

I did some research and came across this site

http://paulski.com/zpages.php?id=1913#addendum

Which provides a helpful screenshot of what (I think) the program should display when it's actually copying files. According to the site, I should be seeing something like this.



I have not seen this message, at all, for more than a second or two in the last 20+ hours. All I have seen is screen after screen of bad sector information. The message does pop up after a bad sector is detected, but again, there's no information at all to indicate that files are being copied.

The only thing I can think of to explain this behavior is that the PCB on my source drive is damaged, enough so that it will not allow dd_rescue to actually transfer files.

With that in mind, here are my questions.

1. Does dd_rescue attempt to ignore all of the bad sectors on a drive before it actually starts to transfer files from one drive to another?

2. Assuming that I actually have this many bad sectors on the drive (i.e., that the PCB board isn't damaged and just shooting out errors because it's damaged,) is it normal for bad sector detection to take this long?

3. Is there a limit to the number of bad sectors a drive can have before it's actually unrecoverable?

4. Is there a point at which it would be reasonable for me to terminate dd_rescue altogether, and attempt to clone the drive through other means? (Most likely I'd use MFStools>MFScopy or the JMFS boot disk I found here yesterday.)

(In case anyone is interested, I'll upload video of what's going on later this afternoon.)

Special thanks again to HomeUser, Unitron, and Guy Kuo for all of your help these last few days, and many many thanks in advance for any new insights gathered through this post.

If

dd_rescue can't "Xerox" it, nothing else will either (unless there's some extra voodoo in Steve Gibson's pricey SpinRite program)

That screenshot is about what you should be seeing if all were going well.

dd_rescue

does not copy files.

At least it doesn't know that it is.

As far as it's concerned, the entire hard drive is one big file.

That's the Unix/Linux way, everything's a file.

What it does is copy bytes.

If it comes upon one it can't read, it tries again.

Usually it copies a bunch of bytes at once.

I think the default is like 16 thousand something.

If it hits a snag, it drops down to trying a smaller "bite" of bytes at a time.

I'm pretty sure the default for the fallback is 512, which until the arrival of "advanced format" drives recently, was the size of a single sector.

You should stay with

dd_rescue

from the MFS Live cd v1.4 and run it in reverse with the max set to 512 bytes and the min set to 1

And pull the bad drive out of the freezer and set it on a block of ice with a fan blowing on it.

Okay, I'm kidding about the block of ice. Too many problems when it starts to melt.

Not kidding about the freezer part.

Temperature changes the size of things.

This may or may not affect whether the heads can find the servo track that tells the drive where the other tracks are.

Somewhere in the march from frozen to room temp and beyond it might get lucky.

And if you're the one with the scorch marked chip (everybody's problems start to run together after a while) the last thing you want is that drive getting hot.
__________________
(thisismysigfile)


"I am altering the deal. Pray I don't alter it any further."

Darth TiVo, 14 February, 2011
unitron is offline   Reply With Quote
Reply
Forum Jump




Thread Tools


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Advertisements

TiVo Community
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
vBulletin Skins by: Relivo Media

(C) 2013 Magenium Solutions - All Rights Reserved. No information may be posted elsewhere without written permission.
TiVoŽ is a registered trademark of TiVo Inc. This site is not owned or operated by TiVo Inc.
All times are GMT -5. The time now is 06:44 AM.
OUR NETWORK: MyOpenRouter | TechLore | SansaCommunity | RoboCommunity | MediaSmart Home | Explore3DTV | Dijit Community | DVR Playground |