On 10/12/2012 10:33 AM, Robert Henney wrote:
> I have a jfs partition on a linux 2.6.32 install on which 3 sectors recently
> became unreadable. I was able to write zeros to those sectors using dd and
> the disk appears to think they're fine and readable again; at least no
> sectors are marked reallocated or currently pending by the disk.
> dd of=/dev/sdc if=/dev/zero seek=640 count=1 bs=4096
> dd of=/dev/sdc if=/dev/zero seek=935 count=1 bs=4096
> dd of=/dev/sdc if=/dev/zero seek=1283 count=1 bs=4096
> I would like to find out which files on the disk were in those blocks and
> thus are now damaged. Since I have the logical block numbers I assume I
> can get inode numbers from them somehow.
The data structure in the inode describes the blocks of a file, but
nothing points from the block back to the inode. Assuming that the
blocks are part of allocated files, one could recursively run "hdparm
--fibmap" on every file in the filesystem and parse the output to
identify which files contain those blocks.
There should be an easy way to determine from the block maps whether
those blocks are allocated or not, but I can't think of one. There are
8192 blocks represented in each dmap page, so those three blocks are
mapped in the first dmap page. Looking at the dmaps in jfs_debugfs is
awkward. Maybe it would be useful to add some new command to jfs_debugfs
to walk the metadata and tell you how a block is used. I might play with
that over the weekend if I find time.
> Tried using the 'd' command in jfs_debugfs but am not able to get anything
> that remotely looks correct. Probably I'm not using a correct offset value, but
> I have no idea what I should give it. Is there a better method?
"d 640 0" should just show you the zeroed block, but it won't tell you
what it is used for. I don't think it will help.
> Disk /dev/sdc: 3907029168s
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Number Start End Size File system Name Flags
> 1 2048s 3907028991s 3907026944s jfs primary