[nycbug-talk] drive failure?
carton at Ivy.NET
Tue May 8 14:14:41 EDT 2007
>>>>> "jv" == Jonathan Vanasco <nycbug-list at 2xlp.com> writes:
jv> thats what has me confused - it *looks* like a hardware issue,
jv> but it stopped when i fsck'd.
<shrug>. maybe it'll start again.
Anyway sometimes you have a drive that is only slightly bad, a drive
that has ``forgotten'' what's stored in a few sectors. Maybe this
could happen on a good drive if the power supply was dipping while it
was writing that sector? or vibration? I don't know. but if you 'dd
if=/dev/zero of=/dev/ad0 bs=56k' to write zeroes over all those
unreadable sectors, this sort of drive will work perfectly again.
In the old days, when a drive started to fail in this way, it was all
but guaranteed to fail completely in the near future, so the
writing-zeroes trick was more a scheme for luring you toward larger
amounts of data loss than an actual trick. I'm not sure if this
remains true of these new ridiculously high-density drives. This
issue is also why, when testing a drive with 'dd', you should first
test by reading, not by writing.
fsck could imagineably function like 'dd if=/dev/zero' if it happened
to overwrite all your unreadable sectors, but that seems far-fetched.
I'd sooner bet that you jostled a cable into a more favorable EMI
If you're putting this on a wiki, you should also note:
dd if=/dev/ad0 of=/dev/ad1 bs=512 conv=noerror,sync
I think this doesn't apply to your situation, but that's how you
recover data from a partly-bad disk. By substituting zero sectors on
ad1 for all the unreadable sectors on ad0, you can get fsck and the
filesystem layer to actually read stuff off the partition, although
the insides of some files will be changed without your noticing.
There's also a program called 'dd_rescue' out there somewhere which will
do this job faster by adjusting 'bs' to copy contiguously-good regions
of the disk faster---that can be important because some bad disks seem
to get worse as you read them. I tried it once, but stick with dd
because dd_rescue seems goofy and Linuxy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 304 bytes
Desc: not available
More information about the talk