Re: [Bug-ddrescue] ddr rescue

[Ryan Zmuda]

Hello,

I went and restated the program but, I don't say any way to open the
previous and restart the process.

Is there any way to do that? I am using ddr rescue gui.
Do I need to do something in terminal?

Ryan

On Tue, Jul 16, 2019 at 4:48 PM Antonio Diaz Diaz <address@hidden> wrote:

> 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
> <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.
>