bug-ddrescue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-ddrescue] An alternative skipping strategy


From: Radorn Keldam
Subject: [Bug-ddrescue] An alternative skipping strategy
Date: Thu, 5 May 2011 08:18:52 +0100 (BST)

Hi:

I'm using this program to recover a quite damaged disk, but I'm having to keep 
stopping it and inserting alternative start point manually when it finds a hard 
zone due to the particular damage pattern this disk has, which ddrescue doesn't 
seem to handle very intelligently.

ddrescue's skipping strategy seems to be geared towards very localized damage 
while my disk has a good deal of damage spread in what seems to be a ratehr 
constant pattern through all of the disk.
apart from unrecoverable damage it also has "hard parts" on which ddrescue (and 
all other recovery programs I tried before) spends a lot of time for very 
little data.

The first time I ran ddrescue, when it hit the first error, it started skipping 
blocks in geometrical progression. it was noticeable when it jumped 1gib, then 
2, then 4, 8, 16, 32, 64, 128 gb...
it's a 160gb disk so it ended the first pass quite fast, but then it slowed to 
a crawl on hard zones during the trimming pass.

The thing is the disk has good dat all over, but ddrescue just hit bad zones 
after every jump, assuming all in between was bad to, and then stalling with 
hard to read parts.

I had to go manual.
In most of this disk there seems to be a rather constant pattern of 50-70mib of 
"hard zone" and then 150-200 (or enven more at times) of easily readable data, 
so what I did was stop the program after it hit a problematic zone (reducing 
cluster size to 1 to reduce the response time, because it was crazy with the 
default 64kb clusters), and start it again with a start point that was 50-70 
mib higher than the last good read. this afforded me a long wait (and possible 
unreasonable skipping and worthless and dangerous attempts at reading bad areas 
before good ones) and once the disk started responding again, it ran through 
the next 150 or so megabytes at normal speeds, and then repeat, and repeat, etc.
Eventually when I finish this I'll let it run normally on what's left 
(untrimed/unsplit areas), but for now the default skipping strategy just 
doesn't work for me.

So, my suggestion is as follows.
Make a new mode so the user can specify custom skipping patterns:
In my case it would be like:
unpon hitting a problematic zone (read error or just a "slow/hard zone") that 
makes recuing stall, jump 50mb, if still no good data found, jump an aditional 
10, then 20, then another 10 or 20. if, after a number of errors you haven't 
found good data, make a bigger jump, like 200mib or 500 then start with 
10-20-50 again. and optionally the geometric progression could be implemented 
too as last resort.

possible commandline argument could be

--skipping-pattern=50Mi,10Mi,20Mi,10Mi,20Mi,200Mi,50Mi,g10Mi

what this would do is try intial jump of 50Mib. if no good area is found, try 
10Mib more, then 20, then 10, then 200, then 50Mi again then geometric 
progression augments of 10, 20, 40, 80, 160, etc megabytes (g of geometric)

or something like that... xD the pattern description format can surely be made 
more inteligent and flexible, but seeing how my disk is, it would probably work 
for me.

additionally, before the trimming step (which, as I understand it, consist of 
reading clusters from the tail), add an additional similar step could be added 
just after the initial read.
it would consist of reading clusters (or a specially specified ammount of data, 
like 1mib, for example) from the start of the jump landing points.
That is, say the intial forward read made a jump from the 150Mib position to 
the 220 position, but maybe there are still some "easy" data at 219mib position 
or before.
instead of trimming clusters, trim zones, starting at the initial points 
(landing zones) of successful reads after a jump.
so if the first read through landed at 220, then try reading 219, then 218, 
then 217, etc until a bad zone is found.

now to define what is a bad zone (or specifically what is a SLOW zone) a few 
metrics could be defined, like "average read speed in the last 10 seconds" or 
something else that denotes that time is being spent on a bad zone while you 
could be trying somewhere else for bigger profit and leave the slow zone for 
later xD



reply via email to

[Prev in Thread] Current Thread [Next in Thread]