bug-ddrescue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Deutsch
Subject: Re: [Bug-ddrescue] Feature Suggestion: Automatic Cooldown mode
Date: Sat, 1 Feb 2014 17:46:10 +0100

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]