I am recovering an 80-GB HDD and V1.10 seems much slower than the original version I was using (1.2?) - currently has been running for nearly 24 hours...
The logic of the old version was fine as it only read a failing sector twice - once when it tried to read the 'large' block of sectors, then again when it was reading the smallest possible group of sectors (native block size). Now I suspect that failed sectors are being read multiple times - unless there is some cleverness going on with identifying how many sectors were read successfully on a failed 'large' read... I suspect the 'trim' works by reading until an error is hit & it looks as though the split process doesn't always drop to the raw block size but tries to read larger blocks initially? It is 'expensive' in time to read a failed sector - on the current disk it is causing IDE bus resets every time a failed sector is hit which is causing it to run at a snails pace! Regards David Mitchell _______________________________________________ Bug-ddrescue mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-ddrescue
