Hi all!
I've just learned of ddrescue a few days ago - but I'm quite happy
that I did.
(I got annoyed about dd_rescue getting almost stuck on a group of bad
sectors about halfway through the drive, slowing down to ~10kByte/s
over hours).
So far I'm quite impressed by ddrescue - it's really a nice approach
at recovering data from a broken/dying hard disk, thank your for
writing it :-)
About my suggestion (sorry for writing that much, but I apparently am
unable to explain it in less words):
I have been "enjoying" the opportunigy to observe the recovery process
of my failing 2 TB HDD over the past days and also used this
"opportunity" to play around a bit with the --input-position parameter.
I have observed that there sectors on my failing HDD can be
categorized in these four groups regarding performance:
"good" sectors - they can be read/copied without any IO errors at
50MByte/s or faster
"slow" sectors - they can be read without any IO errors, but the speed
is around 1-20 MByte/s
"very slow" sectors - they can be read without any IO errors, but
speed is <1MByte/s
"bad" sectors - they can not be read and return IO errors, speed
When looking at how they are spread over the drive I noticed, that
"bad" sectors are virtually always surrounded by a group of "very
slow" sectors, which itself usually are surrounded by "slow" sectors.
This means that over large percentages of the drive I get data copied
to my image at almost full speed (50-80MByte/s average).
Then ddrescue runs into a group of "slow" sectors, possibly followed
by "very slow" sectors, resulting in the "current rate" dropping down
for a long time (hours) although the affected data area is just a few
MBytes in size.
Sometimes there's a read error in this slow area and ddrescue will
skip a few sectors, which is great as it saves a lot of time compared
to dd_rescue (which would try to read every single sector immediately)
- but still ddrescue will have to struggle its way through this slow
area, spending a lot of time there before it will resume with the
remaining data.
A few MBytes later there's finally good sectors again which can be
read at full speed.
I understand that ddrescue already optimizes the recovery by
postponing reading of damaged areas to a 2nd, 3rd, etc. pass.
It would be really great if there was a way to influence this behavior
so that e.g. sectors that prove to be slow when reading them (e.g.
reading 64KiB takes more than 5 ms) will also cause ddrescue to skip x
MByte of data in the first pass.
Looking at my drive here (and looking back at failed HDs in the past),
this approach would allow to have a major part of the data recovered
within just a few hours - which might be crucial when the HDDs state
is further deteriorating during recovery.
I kind of manually tried to do this by stopping ddrescue (Ctrl+C) and
starting it again with an incremented --input-position - from my
impression it would work. But doing this manually is really tiresome.
Having looked at the code a bit, I would assume that implementing this
into ddrescue might not take too much of an effort (introduce a "slow"
state for the logfile, measure the time taken by the copy_and_update()
call, etc?).
Maybe you could give this suggestion a thought or two?
Kind Regards
Felix Ehlermann
_______________________________________________
Bug-ddrescue mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-ddrescue