Reading over J. F. Patenaude's note, and the smartmon howto:
I was wondering whether running e2fsck with the bad blocks
flag is all that is needed?
# umount /dev/hdb1
# e2fsck -c /dev/hdb1
If the bad block test encounters an error
during the read step of the non-destructive read/write test, will it
attempt to write back a block filled with zeros? Or will it just stop
in its tracks and mark the block as bad?
I could see where badblocks probably just returns back the block in
error so that e2fsck can check to see if the bad block is inside of
a file, and in that case, move it to lost+found, or whatever it does
in that situation. Otherwise if badblocks wrote back a zero block,
and this cleared the error, then e2fsck would be unaware of the fact
that the error appeared inside of a file.
Once e2fsck and badblocks have done their thing, and assuming that
badblocks didn't write back a zero block, we might safely be able
to zero out the block that the SMART diagnostics are complaining
about, since presumably e2fsck has attempted to recover what it
can of the file/inode/superblock, and any bad blocks have been marked.
Once we zap the block, and hopefully it is relocated to an alternate
sector, we can safely run 'e2fsck -c' again, and perhaps our
bad block(s) can now be safely used again.
BTW, I think the safest thing to do is probably to run e2fsck -c,
then backup the entire file system, and rebuild the file system,
first running the destructive read/write test (by specifying -c twice
on the mke2fs command), and rebuild and reload the file system.