Wow. I hate when shit like this happens.
Apparently there are three tools out there to help with the same thing. First, there’s dd_rescue, the tool I was using earlier (which ships with Ubuntu in a debian package called… ddrescue). Then, there’s dd_rhelp, a shell script which is a frontend to ddrescue and which implements a rough algorithm to minimize the amount of time waiting on bad block reads.
Then, there’s GNU ddrescue, which is a C++ implementation of dd_rescue plus dd_rhelp.
I only just realized this and so now I’ve compiled a version of GNU ddrescue to pick up my recovery effort. It’ll probably help with one of the partitions that seems particularly messed up.
So far the nice thing about GNU ddrescue is that it seems faster, and more responsive. Plus, it has a real logging feature, such that if you enable it and then CTRL+C the app, you can restart it and it’ll automatically pick up where it left off.
UPDATE: wow, good thing I switched. GNU ddrescue is significantly faster just in terms of raw I/O performance. I jumped from 4GB of this partition being rescued (which took 30 minutes with dd_rescue) to 6GB in the last ten minutes. It seems at least 3x faster. I also like that the GNU info page describes the algorithmic approach in-depth.