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

[David Deutsch]

Quick update - Seems like speed is indeed improving (slightly redacted
for space):

GNU ddrescue 1.18-pre6
rescued:     1724 GB,  errsize:  20839 kB,  errors:   40691
Current status
rescued:     1727 GB,  errsize:   7905 MB,  current rate:        0 B/s
   ipos:    67746 MB,   errors:   41269,    average rate:    64877 B/s
   opos:    67746 MB, run time:   14.03 h,  successful read:    4.25 m ago

GNU ddrescue 1.18-pre7
rescued:     1727 GB,  errsize:   7905 MB,  errors:   41269
Current status
rescued:     1731 GB,  errsize:   7961 MB,  current rate:        0 B/s
   ipos:   126676 MB,   errors:   46430,    average rate:    81727 B/s
   opos:   126676 MB, run time:   12.70 h,  successful read:    1.56 m ago

GNU ddrescue 1.18-pre7
rescued:     1731 GB,  errsize:   7961 MB,  errors:   46430
Current status
rescued:     1739 GB,  errsize:   8002 MB,  current rate:        0 B/s
   ipos:   265035 MB,   errors:   56698,    average rate:    84609 B/s
   opos:   265035 MB, run time:    1.01 d,  successful read:    2.40 m ago

GNU ddrescue 1.18-pre7
rescued:     1739 GB,  errsize:   8002 MB,  errors:   56698
Current status
rescued:     1747 GB,  errsize:   8032 MB,  current rate:        0 B/s
   ipos:   410285 MB,   errors:   65780,    average rate:     108 kB/s
   opos:   410285 MB, run time:   20.97 h,  successful read:    1.43 m ago

Close to breaking 1750GB, too. I think this kills the "1/8 of the disc
is dead" idea, ie. one platter/side or read head being dead. Still
curious what could produce such a regular error, though. Particularly
across the entire space of the disc. Or maybe I just have no frigging
clue how hard discs werk (I really don't).

Reading still progresses in a steady pace in general, although it's
kind of weird: It only reads every two to three minutes, sometimes up
to ten. Not sure whether that is the drive hardware failing more, in
general (though speeds improving would say otherwise) or just the
general issue with bad sectors. Then again: Shouldn't it just skip
past those? Or are the sectors around the bad ones just hard to get
anything out of?

This is what it looks like now in ddrescueview, btw:
http://i.imgur.com/o6tlihz.png (slightly resized the window compared
to my earlier screenshot).

cheers,
David

On Sat, Feb 1, 2014 at 5:46 PM, David Deutsch <address@hidden> wrote:
>>Try it with your current logfile, without giving it the -A option again. I 
>>hope it will speed up your rescue.
>
> So far, pre7 runs at 85kb/s while pre6 ran at 65kb/s. Might just be
> due to the structure, but yeah, faster so far.
>
>> I do not maintain ddrescueview, but surely Martin is reading this. ;-)
>
> Yup, that was what I was counting on. If he doesn't show up, maybe
> I'll write him separately later. It is a pretty sweet tool, but there
> are a few simple (and I think non-controversial) changes that I think
> could improve it.
>
> cheers,
> David
>
> On Sat, Feb 1, 2014 at 1:21 AM, Antonio Diaz Diaz <address@hidden> wrote:
>> David Deutsch wrote:
>>>>
>>>> It could also be useful to have the final logfile to see where are the
>>>> unrecoverable errors.
>>>
>>>
>>> Alright, I will try to keep that in mind. If I fail to do that, feel
>>> free to remind me, as I would be happy to share.
>>
>>
>> I have just noted it in the todo list of ddrescue. Thanks.
>>
>>
>>
>>> First, the error count had been at 26460 before and starting the
>>> command with -A made it jump to 40691:
>>
>>
>> This is normal. For example, every -*- sequence, which counts as one error,
>> is converted to -?- which counts as two errors. (There are 40689 bad-sector
>> areas in the logfile).
>>
>>
>>
>>> It is quite slow right now, but I suppose that is because I had
>>> already gone over that area of the drive without the -A option and
>>> there aren't any large sectors left in the beginning. Once it does
>>> find one of the good sectors, it does seem faster already, though. So
>>> overall, it's about the same speed, it just switches between 0 B/s and
>>> even hundreds of kB/s at times.
>>
>>
>> I think what was making ddrescue slow before the -A was the reading of
>> enormous non-trimmed areas sector by sector. To avoid the recreation of such
>> areas, I have just modified ddrescue to not mark skipped blocks as
>> non-trimmed, but try them in additional passes (before trimming), just as in
>> the case of slow reads.
>>
>> You can find the modified version here:
>> http://download-mirror.savannah.gnu.org/releases/ddrescue/ddrescue-1.18-pre7.tar.lz
>>
>> Try it with your current logfile, without giving it the -A option again.
>>
>> I hope it will speed up your rescue.
>>
>>
>>
>>> The other observation is not strictly for you - but having
>>> ddrescueview running on the side and marking everything as non-tried
>>> was a little bit of a shocker, because the color for that is a dark
>>> gray. For some reason, that looks even worse than the red for the Bad
>>> Sectors - like these blocks aren't just bad, they're already dead!
>>> Just my two cents, but maybe a lighter color is the better choice
>>> here, since we're assuming those blocks to be fresh for checking?
>>
>>
>> I do not maintain ddrescueview, but surely Martin is reading this. ;-)