On October 12, 2014 8:02:37 AM EDT, Otto Rodusek
Greg pointed me in the correct direction with the parameters (--skip-size and -N) which more or less resolved the issues.
I would still be curios as to where/what causes the bottleneck - yes I do know that when an error sector is found the system tries (many times) to recover the sector with multiple reads - this is the part that I was
hoping to resolve - whether there is a parameter or command to ignore the error sector and don't waste time on recovery when I know it's bad/dead. If it's a function of the drive firmware then there's no hope
If a large skipsize helped then you likely had a true head crash. A track is roughly 1 MB on a modern drive. Let's say you had a head crash in the middle of writing some data, that could take out numerous physically adjacent tracks on one platter surface. (Ie. The head is wider than one track, so if it hits the surface it takes out multiple tracks in a single disk revolution.) But the tracks from different surfaces are interlaced so is logically more spread out. Thus if you have damage to 5 physically adjacent tracks(5 MB lost), the logical spread of that damage is likely 4x that or 20 MB. I've seen damaged areas on a platter clearly visible to the human eye (assuming you disassemble the drive after boudoir recovery effort). Ddrescue with default params would hit that 20 MB spot and only bump ahead 64 k after each error as I recall. If so it would take 300 or so bumps to get past the damage. If each bump takes a minute because of retries, that's 5 hours delay because of that one section of bad media. A large skipsize let's you quickly jump past areas where a disk head crash happened. If Turkey curious, once you are done doing the recoveries up the drive and inspect the platters for physical damage. If you can see it, then it was bad. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org