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.
_______________________________________________
Bug-ddrescue mailing list
Bug-ddrescue@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-ddrescue
