[Top][All Lists]

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

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

From: Scott Dwyer
Subject: Re: [Bug-ddrescue] Feature Suggestion: Automatic Cooldown mode
Date: Fri, 31 Jan 2014 20:25:22 -0500
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

I would like to add my 2 cents to this. I have a drive with a very similar pattern (by looking at the ddrescueview image), and have been sent a log from another rescue that was also similar. Both finished logs showed something interesting, in that there were many small errors in what could almost be considered a spiral pattern (it ends up being a sort of "wide" pattern like you are already seeing, not a nice and neat single line pattern, likely do to how the data is physically laid out). And by small errors I mean almost all the errors were only 1-4 sectors large when the rescue was finished. My take on this is that something bad happened while the drive was seeking (head moving across the platter). Either there was a write being performed during the movement, or there was a head crash (piece of dirt or other head contact, possibly due to the drive not being up to proper rpm). But I could be wrong, that is just my opinion.

The recovery that I did was 160GB, had over 61,000 errors (but only .05% errorsize, meaning 99.5% recovered), and took 30 days to complete using ddrescue. About 1/3 of the picture files had an error which could make them look funny. Most of the video files had errors in them, but that would just cause a small glitch. Many small text (Word) documents were recovered just fine. The bigger the file, the more likely to have error(s). The fun part was that the filesystem (it was an NTFS disk) was so messed up that nothing would mount it, and even testdisk failed to find a large portion of the files. So be prepared to use something more robust than testdisk (like R-Studio) if you go through with the rest of the recovery. I am sure that there were files that were just totally lost, but I was surprised that I was able to recover as much as I did. Although I did kind of write my own software for the recovery (and hence my public ddrutility software was able to grow from what I learned).


On 1/31/2014 4:34 PM, 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.

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?


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

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.
Bug-ddrescue mailing list

reply via email to

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