[Bug-ddrescue] Long delays on bad parts of disk

[David Morrison]

Hello

Thanks for making ddrescue. It seems to be a great tool for copying 
disks with problems.

I came across it, of course, when I had a failed disk. Having tried a 
few tools without success, a friend suggested dd, and that somehow 
led to dd_rescue and then ddrescue.

I'm using ddrescue on a Power Mac G4 with Mac OS X 10.4.10. It 
certainly compiled without problems, and seems to work without 
problems, except for one thing.

When it is reading the good parts of my disk, it seems to work well. 
When it hits a problem, it seems to sit there for hours trying to 
read the blocks in it. For example, today, it took around 8 hours to 
read 11MB of a bad spot. While it is doing this, ddrescue does not 
respond to Ctrl/C or any other interrupts. Closing the terminal 
window kills ddrescue, but the device seems to be still locked, as 
nothing else will access it, eg, pdisk -l just sits there waiting.

The disk is in an external case, and if I turn the power off then on 
again, it will often reappear and I can start ddrescue again.

The documentation seems to imply that with the command options I 
selected, it should just skip the bad bits and continue on to get as 
many of the good parts as possible. In practice, it seems that it 
might be continuing to retry, perhaps with a smaller block size. As 
time goes by, the disk seems to be getting sicker and sicker, so 
spending all this time on the bad areas is reducing the chances of 
getting the rest of the good data back.

This is the command I used:

/usr/local/bin/ddrescue -n -i1000M /dev/disk2s10 
/Volumes/127GB/ddr-disk2s10.dmg /ddr-disk2s10.log

I was working on partition 10 of the disk. This is pdisk -l for the disk:

Partition map (with 512 byte blocks) on '/dev/rdisk2'
 #:                type name                    length   base      ( size )
 1: Apple_partition_map Apple                       63 @ 1
 2:      Apple_Driver43*Macintosh                   56 @ 64
 3:      Apple_Driver43*Macintosh                   56 @ 120
 4:    Apple_Driver_ATA*Macintosh                   56 @ 176
 5:    Apple_Driver_ATA*Macintosh                   56 @ 232
 6:      Apple_FWDriver Macintosh                  512 @ 288
 7:  Apple_Driver_IOKit Macintosh                  512 @ 800
 8:       Apple_Patches Patch Partition            512 @ 1312
 9:          Apple_Free                         262144 @ 1824      (128.0M)
10:           Apple_HFS Apple_HFS_Untitled_2 133955584 @ 263968    ( 63.9G)
11:          Apple_Free                         262144 @ 134219552 (128.0M)
12:           Apple_HFS Apple_HFS_Untitled_3 133934616 @ 134481696 ( 63.9G)
13:          Apple_Free                         262144 @ 268416312 (128.0M)
14:           Apple_HFS Apple_HFS_Untitled_4 219718696 @ 268678456 (104.8G)
15:          Apple_Free                             16 @ 488397152

Device block size=512, Number of Blocks=488397168 (232.9G)
DeviceType=0x0, DeviceId=0x0
Drivers-
1:  23 @ 64, type=0x1
2:  36 @ 120, type=0xffff
3:  21 @ 176, type=0x701
4:  34 @ 232, type=0xf8ff

Do you have any idea what might be going on here?

Is there a debug mode that will display what it is doing when this 
happens? If not, it would be helpful to be able to create a record of 
what ddrescue is doing.

(The system log shows some information - there are lots of lines 
saying "media not present", and occasionally "I/O error" for the 
disk.)

So I guess my questions are:

1. Why does ddrescue seem to lock up for extended periods trying to 
read a small part of the disk when it is supposed to be doing a quick 
recovery of the good parts of the disk?

2. Is there a file or debug mode that says what it is doing at any 
given time? (The log file seems to give an end summary of what has 
happened, rather than an indication of what ddrescue is doing at any 
given time.)

Thanks

David
--
David Morrison
PO Box 105, Cardiff, NSW 2285, Australia
David_Morrison at internode.on.net
Ph +61 2 49546164
IT Consulting and Support