Identify damaged files
This article gives details on how to find out which file owns a given block. The main purpose for doing so is finding out which file was damaged in the event a storage device develops any bad blocks. Currently, JFS will be the only filesystem covered by this article but there should be similar tools available for other filesystems.
For these commands you will have to either be root or a user that has direct read access to the drive you are scanning. As usual, a current backup is always a good idea, especially if imminent drive failure is suspected.
Finding Bad Blocks
Just use the badblocks command. There are a few scan modes supported by it. There's read-only mode (default) which is the least accurate. There is the destructive write-mode (-w option) which is the most accurate but takes longer and will (obviously) destroy all data on the drive, thus making it quite useless for matching blocks up to files. There is finally the non-destructive read-write mode which is probably as accurate as the destructive mode, the only real downside of which is it's probably the slowest. However, if a drive is known to be failing then read-only mode is probably still the safest.
To do a verbose read-only scan run this command (with x being the drive letter and y being partition number you want to scan):
badblocks -v /dev/sdx
badblocks -v /dev/sdxy
The downside to scanning the drive as a whole is that each filesystem is going to start its block count relative to the partition it's on. This means that if you have a bad block on let's say the second partition and the second partition starts on block 1000, then you have to subtract 1000 from your block number to get the number you want. The alternative is if you've scanned the drive as a whole and have found bad blocks, figure out the partitions they fall on then scan those, using the new block numbers that result from that.
Another thing to note is that badblocks defaults to 1024 byte blocks so you will either have to change the default size with the -b option to match your filesystem or manually convert the block number(s) later.
If you need to figure out where your partitions start and end run fdisk (older versions might have defaulted to cylinders, not sure. If so the -u option will change the default unit to sectors). Make sure to note the block size fdisk is using so that you can convert the block counts to match your scan.
fdisk -l /dev/sdx
Debug the Filesystem
jfs_debugfs will give you access to all the low level structures within any JFS filesystem. Other filesystems such as the EXT filesystems have similar tools. It is probably a good idea to umount any filesystem before you run this on them. To use it just run:
This puts you into a command console. The first thing you should note is your aggregate block size. This is (presumably) the block size the filesystem is using. JFS seems to default to 4096 bytes. If you did not run badblocks using block size that your filesystem is using then you will need to convert your block numbers to match it (i.e. block number 100 with a block size of 1024 bytes becomes block number 25 at 4096 bytes).
Now the entire point of running this program for the purpose of this article is to get the inode number. To do this run the command:
d blocknumber 0 i
The syntax is the d command for display, the block number, the offset (just set it to 0), and the display format i for inode.
The decimal number that di_number is set to is the one we want. From here you type x to exit out of the display mode. Repeat the display command for each bad block that you have and note all of their inode numbers. For more info on the inode such as permissions and filetype type:
i of course stands for inode.
When you have all the inode numbers type q to quit.
Find Damaged Files
Finally to find the damaged file you can simply use the gnu find utility. Mount your filesystem and run:
find / -inum inodenumber
Substitute "/" for the mountpoint of the filesystem that the inode belongs to. If you search root and have more than one filesystem mounted (who doesn't?) you can find multiple files with the same inode number on different filesystems. Remember, an inode is only unique to the filesystem that it's in.