Re: [Bug-ddrescue] Recovery Advice - Slow + High Error Rate

[Scott Dwyer]

This is the second attempt at sending this email, as the first has not appeared in the bug list yet (after over 4 hours. and normally never takes that long). If it ends up being a duplicate, I apologize.


Niklas,

First, read everything that Felix said in his reply.

Second, try using the "-d" option (--direct). I have found that direct disk access can be 3 times faster at processing read errors, although your mileage may vary.

Third, you are likely seeing a large error size because of the "-c 1Ki" in your command, as it is reading in 1024 sector blocks. This means that no matter what size the error actually is, it will report the size of 1024 sectors on the first pass, for example (1024*512*644=337641472). This number is close to what you show, so I would say that you have many individual errors and not many large groups. I would recommend trying with the option "-c 1" and see what the log says for that part of the read. You could find that you have many small or single sector errors. Is this drive from a laptop? It could have been "bumped" at just the right angle at just the right time, and the head moved across the platter while performing a write. Look for patterns in the log file.

If you do find that you have many single sector errors, you might be better off sticking with the "-c 1" option. It will make for slower reads in good parts of the drive, but there won't need to be any trimming later (as long as you are using ddrescue 1.17 or newer).

Here is an example below. Notice that all the errors are 0x200 in size (512 bytes, one sector). Also notice that there are 2 patterns of good read size in between the errors. That was from a 160GB laptop drive, and it took 30 days to do a full image. Using ddrescueview (http://sourceforge.net/projects/ddrescueview/) on the log file, a very neat "curved" pattern appeared, indicating what looked like a spiral write. You could try using ddrescueview on your partial log file to help see any patterns, although you still should look at the actual log file.

If you see some interesting patterns, you could post a section of your log file and let the experts look at it, like so:
  (don't let the command line on this one confuse you, I was performing some "magic").

# Rescue Logfile. Created by GNU ddrescue version 1.18-pre2
# Command line: ddrescue -v -d -c1 -i45512474624 -o94961664 -s67051520 /dev/sdg2 _inode_0_$MFT _inode_0_part1_$MFT.log
# current_pos  current_status
0xA9CBEC800     +
#      pos        size  status
0x00000000  0xA98C14000  ?
0xA98C14000  0x0232B200  +
0xA9AF3F200  0x00000200  -
0xA9AF3F400  0x000B3E00  +
0xA9AFF3200  0x00000200  -
0xA9AFF3400  0x00238000  +
0xA9B22B400  0x00000200  -
0xA9B22B600  0x000B3E00  +
0xA9B2DF400  0x00000200  -
0xA9B2DF600  0x000B3E00  +
0xA9B393400  0x00000200  -
0xA9B393600  0x000B4000  +
0xA9B447600  0x00000200  -
0xA9B447800  0x000B3E00  +
0xA9B4FB600  0x00000200  -
0xA9B4FB800  0x000B3E00  +
0xA9B5AF600  0x00000200  -
0xA9B5AF800  0x00238000  +
0xA9B7E7800  0x00000200  -
0xA9B7E7A00  0x000B3E00  +
0xA9B89B800  0x00000200  -
0xA9B89BA00  0x000B3E00  +
0xA9B94F800  0x00000200  -
0xA9B94FA00  0x00168000  +
0xA9BAB7A00  0x00000200  -
0xA9BAB7C00  0x000B3E00  +
0xA9BB6BA00  0x00000200  -
0xA9BB6BC00  0x000B3E00  +
0xA9BC1FA00  0x00000200  -
0xA9BC1FC00  0x002EC000  +
0xA9BF0BC00  0x00000200  -
0xA9BF0BE00  0x000B3E00  +
0xA9BFBFC00  0x00000200  -
0xA9BFBFE00  0x000B3E00  +
0xA9C073C00  0x00000200  -
0xA9C073E00  0x00168000  +
0xA9C1DBE00  0x00000200  -
0xA9C1DC000  0x00183E00  +
0xA9C35FE00  0x00000200  -
0xA9C360000  0x000B3E00  +
0xA9C413E00  0x00000200  -
0xA9C414000  0x000B4000  +
0xA9C4C8000  0x00000200  -
0xA9C4C8200  0x000B3E00  +
0xA9C57C000  0x00000200  -
0xA9C57C200  0x000B3E00  +
0xA9C630000  0x00000200  -
0xA9C630200  0x00168000  +
0xA9C798200  0x00000200  -
0xA9C798400  0x000B3E00  +
0xA9C84C200  0x00000200  -
0xA9C84C400  0x00183E00  +
0xA9C9D0200  0x00000200  -
0xA9C9D0400  0x00168000  +
0xA9CB38400  0x00000200  -
0xA9CB38600  0x000B3E00  +
0xA9CBEC400  0x00000200  -
0xA9CBEC600  0x00019A00  +
0xA9CC06000  0x18354FA000  ?

Scott

On 10/18/2013 1:29 AM, Niklas Swan wrote:

Hi guys,

this isnt a bug as such, but I've spent time tying to find the right forum to get advice about GNU DD-rescue, and this seems to be the only avenue.

I've spent quite a bit of time learning about how DDrescue works, but I need advice on the following topics with my current recovery, and what I can do to speed it up if possible.

ok, so when I started it was going very slow, like, only bytes or maybe a few kb. then I changed the script a bit:

 

sudo ddrescue -f -n -c 1Ki  /dev/rdisk1 /dev/rdisk2 nsclone.log

 

which sped it up a bit:

 

rescued:     9678 MB,  errsize:    309 MB,  current rate:    47662 B/s

   ipos:     9988 MB,   errors:     644,    average rate:     102 kB/s

   opos:     9988 MB,    time since last successful read:       0 s

Copying non-tried blocks...

 

but compared to other people who I hear about getting 20mg average, this is really slow.

 

so Q1 - can I speed this up some more"

 

Q2 - 10gigs in, I have 309mb of damage - is that a lot of damage? how badly damaged is this disk?

 

I did manage to get a few key things off it before starting this process, as it still ran but had errors.

 

Any advice on how to make the process faster, or on how damaged the disk is - i.e should I just accept its dead and not spend 2 months trying to recover it.

any expert advice would be really great, I can deal with a 75 day recovery if I have to, just want to make sure I'm doing it the right way.

Thanks, and apologies as this isn't technically a bug report.

really awesome utility tho! 

niklas

_______________________________________________
Bug-ddrescue mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-ddrescue