>
> I had to do this recently with an IDE drive. First I ran badblocks:
> badblocks -b 1024 -o /floppy/hda1.bb /dev/hda1 1878528
> In my case, the drive was originally mke2fs'd with 1024 byte blocks, so the df
> output gave me the total number of 1024 byte blocks on the partition. This
> created a file that I put on a floppy with a list of blocks that it found that
> were bad. Then I used e2fsck to add the blocks to the bad list:
> e2fsck -l /floppy/hda1.bb /dev/hda1
> There's another version of -l to e2fsck, -L, that replaces the current bad
> block list with the one in the file. When e2fsck runs, it gives the option to
> copy the bad block if it is in use, and tells you what file had the bad block
> in it (at least it did for me -- fortunately none of the bad blocks were
> inodes). I didn't choose to do this. I just got the files from a backup rather
> than try to figure out if they were still okay.
This method worked to get the drive operational ... BUT... (see below)
> If the drive is blank, you could do the same thing with /dev/hda, or supposedly
> (I haven't tried this) by using e2fsck from the start with the -c option. I
> know the above method works, just did it a couple days ago.
e2fsck -c did not work FWIW....
But I've found a bug in e2fsck:
If a bad block is in a spot occupied by a superblock backup,
ext2 programs crash (fsck particularily).
Is there anything that can be done about this?
Or am I the first one to have a shipping defect right where Linux likes to
put one of the superblock backups?
TIA and G'day, eh?
- Teunis