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

[Scott Dwyer]

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

Scott


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?
>
> -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.
> _______________________________________________
> Bug-ddrescue mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-ddrescue