6

I have a drive in our iMac that has bad blocks, as booting from an Ubuntu 11.10 live CD and using ddrescue -f /dev/sda /dev/null finds them. I'd like to get the drive to remap them by writing to the blocks, say using hdparm --write-sector, but I don't want to do this without knowing what's in those blocks and finding the file that owns them, so I can restore the file from another source.

I found fileXray but don't feel like spending $79 to map a block to a file and hfsdebug has been taken offline. Are there suggestions on a tool or technique to use?

I looked at all the Ubuntu HFS+ packages to see if they could provide this info but nothing jumped out at me.

BTW, I used Disk Utility to erase the empty space, but it didn't get any of the bad blocks to be remapped, according to smartctl -A.

Glorfindel
  • 4,089
  • 8
  • 24
  • 37
Blair Zajac
  • 201
  • 1
  • 8

1 Answers1

3

If you are running Lion, man fsck_hfs and look at the -B option which says it will print files given a list of block numbers. Note: I had to include -n -f on the command to force a check, otherwise it just reported *** NO MATCH *** for all the blocks in my list.

Also, before attempting to overwrite a block, I'd want to develop and run some test to verify the mapping is correct between block numbers reported by ddrescue and those used by fsck_hfs and hdparm.

Brian Swift
  • 506
  • 2
  • 5
  • 1
    Passing `-l` to `fsck_hfs` seems like a safer way if the filesystem is currently mounted. – Blair Zajac Oct 18 '12 at 23:08
  • I also had to add `-b 512` since, given a plain file (the output of ddrescue) it was unable to automatically determine a blocksize to work in. So, in total `fsck_hfs -n -f -b 512 -B badblocks.txt `, where badblocks.txt was the hex offsets from the ddrescue map.txt divided by 512. Presumably one would also need to subtract off the offset of the start of the partition, but I had actually already done ddrescue on only one partition, rather than the whole raw device. – puetzk Jan 07 '23 at 07:47
  • > before attempting to overwrite a block, I'd want to develop and run some test to verify the mapping is correct I was also able to check this - I picked a file with fairly distinctive contents, and used grep --text --byte-offset 'whatever' partition.img, to find a plain byte offset where that data appeared. fsck_hfs correctly Identified the filename, so its block numbering is indeed just offset divided by 512 (or whatever -b was used). – puetzk Jan 07 '23 at 07:51