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 <[email protected]>: > > Have you experimenting with --min-read-rate and --idirect? > > > On Fri, Nov 25, 2016 at 10:24 PM, Santiago Cassina < > [email protected]> 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 >> [email protected] >> https://lists.gnu.org/mailman/listinfo/bug-ddrescue >> > _______________________________________________ > Bug-ddrescue mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/bug-ddrescue _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
