rescued disk: what to do with the bad blocks that were not copied

my old system disk almost failed me. I dd_rescued the disk onto a new one (don’t use dd_rhelp, that one took days and seemed to forget what it had scanned more than once). The condition of the disk was not very good. So naturally I expected the subsequent fsck.ext3 to bomb half of the new disk. But obviously only a few inodes were affected and I lost only about 10 files completely (mostly on the root partition and not the home partition - yeay!).
However, I then ran a badblocks and put all the bad blocks into a file. I could use this to run fsck but I fear that

  1. It could undo or even redo worse than what the first fsck run did, and
  2. giving the list of bad blocks, fsck might on the one hand rescue/flag damaged files (which is what I want), but I don’t want it to flag the bad blocks on the new disk as well (they are not bad blocks anymore, just copies of bad blocks).

So, how can I single out problematic files using my list of bad blocks (which I can then look at one by one if they could be rescued) without flagging the supposedly bad blocks on the new disk.


Since those bad blocks aren’t really bad, can’t you copy the files to new locations and delete the existing locations? Of course you will get garbage where the bad blocks were but that’s what you would expect anyway.

I guess I have to rephrase: how do I find the files that have one or more bad blocks (usually it’ a sequence of a few: 6296,6297,6298…) in them? Then I can check if I can rescue those files or restore them with some originals.

I guess you need a tool that can find what file a block belongs to. In principle all this information is in the filesystem. Try debugfs. I see there is an icheck command, which gives you the inode owning a block. From that you can use ncheck to get the pathname. At least that’s what I gather from a short perusal of the man page.