Re: [Bug-ddrescue] RFE: option to skip slow areas, and ext[23] rescue script (fwd)

[Antonio Diaz Diaz]

Hello,

J. Randall Owens wrote:
> Firstly, let me add my thanks to those whose data you've helped save.

You are welcome. :-)


> But, I might like to save my data faster, especially since I'm using the 
> freezer trick and don't know how many thermal cycles it can take.  One 
> thing that slows down ddrescue considerably is when it gets to an 
> unhealthy but not unreadable area of the disk, and spends a lot of time 
> getting data at something like 9-40 KiB/s, while the kernel spews drive 
> error messages to the screen. I'd like to be able to skip such areas on 
> a first pass, just getting the stuff that gives me 33-50 MiB/s speeds, 
> and get the slower stuff on a later pass (assuming the drive lasts that 
> long.)

I think the only way that will probably work without interfering with 
other functions of ddrescue is to treat slow areas just like partially 
damaged areas and skip over them in the first pass.

Of course this will need a new option because 40 KiB/s is slow for hard 
disks but not for floppies.


> On another note, I've been creating some perl scripts that let one 
> optimize rescue of an ext[23, maybe4] filesystem.

Scripts are for pioneers. The "general public" already finds difficult 
enough using ddrescue alone. :-) In the long term, to achieve the 
optimization you are seeking, I think some kind of neat interface 
between filesystem-specific tools and tools like ddrescue should be 
developed.

For example, ddrescuelog is already able to create a list of bad blocks 
from a logfile, using the same format that the output of the badblocks 
program, so that it can be used as input for e2fsck or other similar 
filesystem repairing tool.

What I propose is modifying the filesystem-specific tools (or writing 
new ones) so that they create a list of blocks to be rescued by ddrescue.


> Anyway, my point is, if I do put this into a form usable by the general 
> public (right now, I've been mostly putting the options for my system in 
> the code itself), would you be interested in including that in some way 
> in the ddrescue tarballs?

I am always willing to briefly document in the manual how to use 
ddrescue with stable and well-known tools like e2fsck. If some e2 tool 
were modified as I propose above, I would mention it in the manual. What 
I don't think is a good idea is bloating the manual with references to 
the many special-purpose scripts users have written.


Regards,
Antonio.