Sweet! That looks like it's working. Slowly, of course.. There appear
to be more bad sectors than I originally thought. Alas. In the 12
hours it's been running, it's averaging around 715 kB/sec. If that's
representing the average error rate (and I hope it's really worse than
the average error rate...), it should only be another 50 short hours
until it's done! Maybe I should get a cup of coffee...
To Ian's suggestion of dd_restore, looks like that package only improves
upon dd with the hard and soft block sizes, and back-to-front transfer.
Clever, but not clever enough for me to restart the process over 20
hours in.
Thanks for the valuable suggestions!
~Brian
Kevin Otte wrote:
Brian Henning wrote:
*rubs eyes*
There it is, right in front of my face. Thanks for not being a jerk
about pointing out the obvious to me. :-D My excuse is "it's Monday."
The question becomes, then, what is the output when the input is an
error? Garbage or nothing?
By default, nothing. It will only write as much of the block as you
were able to read.
I think it might make for a more difficult recovery (then again,
maybe it won't) if, for example, 100 good bytes + 10 errors [in] ==
100 bytes out, instead of 110 bytes out (10 of which are garbage).
Quite right. This is why you will also need the "sync" option to conv.
That will write NUL bytes in place of what would be garbage.
My references:
http://www.macosxhints.com/article.php?story=20050302225659382
dd(1) manual page
-- Kevin
--
----------------
Brian A. Henning
strutmasters.com
336.597.2397x238
----------------
--
TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
