Re: [Bug-ddrescue] Improving ddrescue

[Florian Sedivy]

And especially try the option --reopen-on-error (in conjunction with 
--min-read-rate) which was introduced for exactly the behavior you noticed. May 
I cite the man-page:

-O
--reopen-on-error
Close infile and then reopen it after every read error and, if 
'--min-read-rate' is set, after every slow read encountered both during the 
copying phase. Use this option if you notice a permanent drop in transfer rate 
after finding read errors or slow areas. But be warned that most probably the 
slowing-down is intentionally caused by the kernel in an attempt to increase 
the probability of reading data from the device. 

Greetings, 
Florian Sedivy


> Am 26.11.2016 um 17:16 schrieb Robert Trevellyan <address@hidden>:
> 
> Have you experimenting with --min-read-rate and --idirect?
> 
> 
> On Fri, Nov 25, 2016 at 10:24 PM, Santiago Cassina <
> address@hidden> wrote:
> 
>> Hello, I use ddrescue a lot to recover damaged disks, most of them are WD
>> (green and blue), I want to share my own experience because I believe it
>> can help improving your software
>> 
>> This story starts with a big 2TB green WD disk, which started to copy at a
>> rate of 32MB/sec with some (fast and very slow) peaks. It was a LOT of data
>> to recover so I spent 6 days running ddrescue constantly (and checking it
>> visually).  I noticed sometimes when the reading speed dropped (very very
>> slow, about 1KB/sec or less) that by pressing CTRL-C and re-running
>> ddrescue the reading speed was fast again (sometimes fast and sometimes
>> very slow as before), so I tried modifying parameters as sector size, block
>> size, dynamic access, reverse direction, but such modifications were not
>> helpful, instead killing and starting ddrescue again with default
>> parameters every 7 seconds helped me to improve read speed.
>> 
>> I didn't read ddrescue sources, so I don't know if it gots stucked on a
>> bottleneck when some read error is found, but the this experience made me
>> to create two bash files
>> 
>> 1)  rekill_recover.sh
>> 
>> #!/bin/bash
>> while :
>> do
>>    echo "Killing again..."
>>    killall ddrescue
>>    sleep 12
>> done
>> (you can try 7-12-20 seconds, the block of time you detect as the best to
>> kill and rerun)
>> 
>> 2) rerun_recover.sh
>> 
>> #!/bin/bash
>> while :
>> do
>>    echo "Running again..."
>>    ddrescue /dev/source /rescued.img /tmp/rescued_img.log
>> done
>> 
>> I used those scripts and I rescued (almost) the entire disk faster than
>> expected. I thought it was just luck
>> 
>> Two days ago I received a very damaged HDD WD (blue this time) with same
>> reading speed drops, I used those scripts again (each one in different
>> terminals obviously) and voilá, I got better reading speeds again, so my
>> "guess" is one of this two options
>> 
>> 1) When I kill ddrescue, "he" forgets what was reading, ignores that block
>> and I lose data (but I BELIEVE this is not happening)
>> 2) When I kill ddrescue, "he" forgets he was reading slowly and starts
>> again with all the power, energy and faith he can do the job
>> 
>> I think 2) is happening, and I want it too
>> 
>> 
>> I don't know if this can help you to improve your software, just sharing
>> my experience.
>> 
>> 
>> By the way, when I detect (visually) that the reading speed is
>> considerably fast again (more than 10MB/sec) I stop killing ddrescue for a
>> while, until I detect he stucks again and I start to call rekill script.
>> Maybe, maybe, maybe you can apply some of this experience on the sources
>> or by creating a simple bash script (I don't think can be better than mine
>> ;) with the ability to do some "smart-automagic" kill-rerun-rekill-rerun
>> depending on reading speeds
>> 
>> If you need to, I can provide with a secure shell connection to a terminal
>> with this second disk connected to check it for yourself. Or perhaps by
>> vnc, teamviewer, anything I can do to help you improving your algorythm
>> 
>> Best regards
>> 
>> --
>> _______________________________
>>        Santiago Cassina
>>  Lic. en Análisis de Sistemas
>>           M.P. 8064
>> Cel/Whatsapp: (0387) 154-752661
>> 
>> 
>> _______________________________________________
>> Bug-ddrescue mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/bug-ddrescue
>> 
> _______________________________________________
> Bug-ddrescue mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-ddrescue