David Deutsch wrote:
Quick update - Seems like speed is indeed improving (slightly redacted for space):
It is nice that speed is improving now, but the gain I was thinking about was a sustained speed for a longer time before trimming.
Close to breaking 1750GB, too. I think this kills the "1/8 of the disc is dead" idea, ie. one platter/side or read head being dead. Still curious what could produce such a regular error, though. Particularly across the entire space of the disc. Or maybe I just have no frigging clue how hard discs werk (I really don't).
To make things difficult, most probably every disc works differently. :-)
Reading still progresses in a steady pace in general, although it's kind of weird: It only reads every two to three minutes, sometimes up to ten. Not sure whether that is the drive hardware failing more, in general (though speeds improving would say otherwise) or just the general issue with bad sectors. Then again: Shouldn't it just skip past those? Or are the sectors around the bad ones just hard to get anything out of?
The sectors around the bad ones are hard to get out of.
This is what it looks like now in ddrescueview, btw:
I am just now testing an idea inspired by your images; making each copying pass run in the inverse direction as the previous one. This should read faster all those large non-tried areas remaining behind the large errors.
In case you feel like trying reverse mode, take into account that reversing direction in the middle of a rescue is tricky. (It continues backward from the current position, not from the end). The following sequence makes the trick:
ddrescue your_options_and_files -i position -s 512 ddrescue your_options_and_files -R Best regards, Antonio. _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
