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 you
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
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-ddrescue
_______________________________________________
Bug-ddrescue mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-ddrescue
