On 5/14/05, Sam Moffatt <pasamio@...> wrote:
> Never had that issue, but shouldn't fsck fix this issue like a normal par=
Only if you specify -c, and even then it only detects the problem, but
does not solve it. Real bad block handling can be a bit tricky,
because modern hard disks actually handle them, but there is little
cooperation with the OS.
The best tool I have found so far is ddrescue (and it is far from
perfect). If you read the whole partition with it, it should log the
precise location of the bad block. Then you have to write this block
(you can use ddrescue again for this). Because you could not read it,
you have to write it with random data, or all zeros. The writing
triggers the bad block relocation on the hard disk controller, and
next time you read this block, it is fine.
Of course you do have an invalid block on your filesystem now.
Usually, you can just ignore that problem (which just proves that we
don't actually need 90% of our data :-)). But you should run a full
filesystem check, just to make sure that no vital structures have been
hit. And you can reinstall core libraries, if you feel so.
Since you know which block was affected, you could actually find out
which file has affected. fsck -c might tell you that, otherwise I do
not know an easy way to do this.
Note that you can run the block checking and fixing either under
(co)linux or under windows, but everything that deals with the
filesystem must of course be run under (co)linux. I guess that windows
also has a tool for checking bad blocks, and maybe you can use that
one instead of fsck -c or ddrescue. I would still run fsck -c first to
find out which file is affected.
Hope that helps.