Re: [Bug-ddrescue] ddr rescue

[Antonio Diaz Diaz]

Ryan Zmuda wrote:
> GNU ddrescue 1.24
> About to copy 1000 GBytes from '/dev/rdisk3' to '/Volumes/FreeAgent
> G/recocered/Untitled.img'
>      Starting positions: infile = 0 B,  outfile = 0 B
>      Copy block size:  32 sectors       Initial skip size: 128 sectors
> Sector size: 512 Bytes
>
> Press Ctrl-C to interrupt
>      ipos:  720602 MB, non-trimmed:        0 B,  current rate:     512 B/s
>      opos:  720602 MB, non-scraped:        0 B,  average rate:   1337 kB/s
> non-tried:  279602 MB,  bad-sector:        0 B,    error rate:       0 B/s
>   rescued:  720602 MB,   bad areas:        0,        run time:  6d  5h 41m
> pct rescued:   72.04%, read errors:        0,  remaining time:   6433d 16h
>                               time since last successful read:          0s
> Copying non-tried blocks... Pass 1 (forwards)

I don't use macs, but it is possible that the kernel has detected a 
problem with the drive and has reduced the read speed "permanently". If 
you are using a mapfile, you may stop and rerun ddrescue. If this 
increases speed, you may try options "--min-read-rate=100kB 
--reopen-on-error":

http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Invoking-ddrescue
-O
--reopen-on-error
    Close infile and then reopen it after every read error encountered 
during the copying phase. If '--min-read-rate' is set, also close and 
reopen infile after every slow read encountered during the first two 
passes of the copying phase. Use this option if you notice a permanent 
drop in transfer rate after finding read errors or slow areas. But be 
warned that most probably the slowing-down is intentionally caused by 
the kernel in an attempt to increase the probability of reading data 
from the device.

Regards,
Antonio.