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: Fri, 31 Jan 2014 22:34:08 +0100

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

> Yes, but just once as you guessed.

Well, it was an "educated" guess ;-) And I've just started running it.
Two things I have observed:

First, the error count had been at 26460 before and starting the
command with -A made it jump to 40691:

GNU ddrescue 1.18-pre6
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:     1724 GB,  errsize:    276 GB,  errors:   26458
Current status
rescued:     1724 GB,  errsize:    275 GB,  current rate:        0 B/s
   ipos:    56290 MB,   errors:   26460,    average rate:     6949 B/s
   opos:    56290 MB, run time:   21.87 h,  successful read:       1 s ago
Trimming failed blocks...^C
Interrupted by user

GNU ddrescue 1.18-pre6
Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:     1724 GB,  errsize:  20839 kB,  errors:   40691
Current status
rescued:     1724 GB,  errsize:  60314 kB,  current rate:        0 B/s
   ipos:   929641 kB,   errors:   40696,    average rate:     5046 B/s
   opos:   929641 kB, run time:    8.48 m,  successful read:    1.66 m ago
Copying non-tried blocks...

Not sure why, but it seems like it picked up the wrong number there.

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.

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?

-David


On Fri, Jan 31, 2014 at 9:55 PM, Antonio Diaz Diaz <address@hidden> wrote:
> David Deutsch wrote:
>>
>> That's what I was hoping! Sending you the image on a separate,
>> personal email with the log file next up.
>
>
> Thanks. It could also be useful to have the final logfile to see where are
> the unrecoverable errors.
>
>
>
>> I'm not too sure about that, actually. When I tell ddrescueview to
>> give me the details on each block, it lists the bad sector as 512
>> Bytes, with about 200megs of non-trimmed data around that. Or maybe
>> that's what you meant?
>
>
> I calculated the mean error size dividing the total error size by the number
> of errors and I guessed there would be large non-trimmed areas. I see in the
> logfile that this is true (there are many multi-megabyte non-trimmed areas).
> I guess many of those large non-trimmed areas will be read fast with
> '--try-again'.
>
>
>
>> So would I simply extend my current command to be from now on:
>>
>> ddrescue -f -n -d -A /dev/sdf /dev/sde logfile
>
>
> Yes, but just once as you guessed.



reply via email to

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