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

[J. Randall Owens]

As promised....

---------- Forwarded message ----------
Date: Sat, 9 Apr 2011 16:15:45
From: J. Randall Owens <address@hidden>
To: address@hidden
Subject: RFE: option to skip slow areas, and ext[23] rescue script

Firstly, let me add my thanks to those whose data you've helped save.

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.)

It seems to me the easiest way to do this might be an option or two which would 
let one specify a maximum time for it to try an area before considering it as 
bad or untried (maybe a new status for slow areas?) and skipping ahead a fair 
bit on the disk, or else a minimum speed below which it should skip ahead.

The timeout would probably be the better option, generally, but I don't know 
whether ddrescue can control disk reads so directly.  Perhaps it could only be 
used with the -d option?  That would defeat the purpose of using it for a first 
preliminary run, though.  Alternatively, if there is a timeout setting that can 
be changed in the /proc or /sys directories, a pointer to those would be an 
excellent start.

The minimum speed would definitely be doable, since ddrescue shows current & 
average speed already.  An option for this could probably use some tweaking, so 
that it doesn't skip just because it slows down for one period to 10 KiB/s or 
something like that; maybe a certain number of update periods below the speed 
given with the option.  This would still be subject to waiting for the kernel 
to give up on the current read operation, though, if I'm understanding how 
ddrescue, the kernel, & the controller interact correctly.

Also, you would have to either figure a good algorithm, or give yet another 
option, for how far to skip ahead when it gets to a slow area. This might be 
tricky, but I hope you'd have better ideas than I would!

On another note, I've been creating some perl scripts that let one optimize 
rescue of an ext[23, maybe4] filesystem.  Basically, they save & read the 
superblock first, so it can find the block group descriptor table.  Save & read 
the BGD, so it can find the block bitmaps, inode bitmaps, & inode tables.  Save 
& read those, so it can send ddrescue after the blocks that actually contain 
data to save, and skip the ones that presumably just contain zeros or deleted 
files.  I'm trying to add an option to let the user specify directories and/or 
files to rescue, but I don't know directory structure well enough yet, and I'm 
not sure whether I'd bother to once I have this partition rescued.  Their 
interaction with ddrescue is quite simple so far.  I just have it send ddrescue 
commands to save the appropriate blocks to stdout, redirect that into a file, 
and use that file as a shell script.  (On my current rescue, that resulted in 
around 7K ddrescue commands!  But it should mean I only have to rescue about 
110GiB, instead of the whole 240GiB partition.)

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?  Probably in some way that it wouldn't usually add a dependency on 
perl in most distributions, maybe as an extra something in the doc directory or 
something like that.

--
J. Randall Owens | http://www.ghiapet.net/
ProofReading Markup Language | http://prml.sourceforge.net/