Re: [Bug-ddrescue] Feature Suggestion: Automatic Cooldown mode

[David Deutsch]

Alright, status update time. It has been nine days so far and about
two days ago, ddrescue switched to trim mode. Rescued data clocks in
at 1724 GB leaving the errors at 276 GB.

The curious thing (well, to me at least, you guys might've seen it all
before) is that there seems to be a pattern to the bad sectors. Here
is a screenshot of ddrescueview:

http://i.imgur.com/gz3Q67U.png

(That's the best I could make it line up)

The thing that is slightly concerning right now is that readout rates
have dropped to ~2-4kb/s. I suppose it's to be expected in the
trimming stage but then I think about that I still have the splitting
and retrying phases ahead of me... While I appreciate the fact that I
might be able to get more out of the drive, my layman
napkin-computation suggest the readout would again end up in the
"hundreds of days" region with trimming already. Quite sure the drive
wouldn't survive that.

So - if somebody knows anything I can do to speed this up, I would be
very greatful for suggestions!

---

I had earlier posted this as a personal reply to Paul. Dang... Mailing
lists, how do they work!

Anyways, would include his insight here:

Yes, I've had this before.  Was a dead head or amp on that one head.
If you're seeing 1/8th lost then it might imply you have a 4 platter
drive.

Nothing much to really speed it up, just one of those things where you
have to wait, especially since you already have all the usable data.
If it's a head failure then you won't get much more.

Maybe someone else can weigh in with their own experience too.

---

Also - This is all still just numbers so far, so does anybody have a
clue on whether a "you have lost 1/8 of your drive to errors" actually
means in terms of getting my data out of the copy? Would I be able to
mount and read from it (simply encountering a lot of broken files) or
would I have to use something like photorec for sure?

Thanks!

On Wed, Jan 22, 2014 at 10:23 AM, David Deutsch <address@hidden> wrote:
> Hey everybody,
>
> I have this failing WD Green Line 2TB drive (SMART counts errors in
> the five figures, tons of bad sectors right through tons of family
> photos that I did not have backed up, like an idiot...) that I'm
> currently trying to rescue and I've come across a possibly interesting
> problem.
>
> I'm making a full disk-to-disk copy using the following command:
>
> sudo ddrescue -f -n -d /dev/sdf /dev/sde logfile
>
> (ddrescue v. 1.16, copying to another 2TB drive)
>
> With that, I'm getting quite good speed rates considering the state of
> the disk - around 50-100MB/s (never much faster than that, though):
>
> Current status
> rescued:    25877 MB,  errsize:   6442 MB,  current rate:   92667 kB/s
>    ipos:    32319 MB,   errors:      94,    average rate:   44372 kB/s
>    opos:    32319 MB,     time since last successful read:       0 s
> Copying non-tried blocks...
>
> However, every time an error is found and ddrescue has worked through
> it (which can take up to a minute):
>
> Current status
> rescued:    26322 MB,  errsize:   6576 MB,  current rate:        0 B/s
>    ipos:    32898 MB,   errors:      95,    average rate:   11393 kB/s
>    opos:    32898 MB,     time since last successful read:      53 s
> Copying non-tried blocks...
>
> ...the speed drops to around just a few kB/s and stays there:
>
> Current status
> rescued:    26324 MB,  errsize:   6710 MB,  current rate:     6144 B/s
>    ipos:    33034 MB,   errors:      95,    average rate:    7615 kB/s
>    opos:    33034 MB,     time since last successful read:       0 s
> Copying non-tried blocks...
>
> Unless I restart it! So I ctrl+c and wait for a bit, restart the
> command and it shoots up to 100MB/s again:
>
> Current status
> rescued:    26555 MB,  errsize:   6710 MB,  current rate:   92798 kB/s
>    ipos:    33265 MB,   errors:      95,    average rate:   38464 kB/s
>    opos:    33265 MB,     time since last successful read:       0 s
> Copying non-tried blocks...
>
> Actually, If I wait a seemingly fixed period of time (I have figured
> out around 20-30 seconds), I get pretty consistent rates that way. I'm
> now chomping at the drive at about 1GB intervals.
>
> I made an earlier attempt where I just let ddrescue run and after
> three days, it was still stuck idling between 32kb and 64kb. At 2TB,
> that would put the time to rescue the full drive in the hundreds of
> days - clearly not a workable solution. I had barely managed to get
> 20GB out of the drive, while, as you see from the examples above, I'm
> now at 30+GB after just about 4 hours or so.
>
> ---
>
> It would appear to me that this is hardware related. Possibly the
> drive simply can't take long copying cycles anymore or is heating up
> slightly (although I have it very well ventilated) in the process and
> doesn't like that.
>
> Maybe there is already a feature for that which I'm missing, but I
> think a "let the drive cool down for X seconds after you've found an
> error" could be a neat addition. It would at least save me a lot of
> manual work ;-)
>
> Among the other things that I have tried were changing the sector
> size, but I started ddrescue with it set to 256k (I think) and it
> instantly claimed that it was finished (wasn't sure how to recover
> from that). Also, using -d seems to have improved my speed in general
> and for a while I also tried -D, but I'm not sure that did anything
> (that one is only about the drive you copy /to/, right?).
>
> ---
>
> If anybody has any tips or suggestions, I'd be more than happy to hear
> about them! As I would be to supply more information about this case
> if need be, of course.
>
> Oh, and - I'm following the 'Example 1' from the manual here, planning on 
> using
>
> ddrescue -d -f -r3 /dev/sdf /dev/sde logfile
>
> for the second pass.
>
> cheers and thanks already,
> David