On Wed, Mar 11, 2009 at 07:44:51AM +1030, Kevin Shanahan wrote:
> Thanks Ted. Just so I know what I'm doing if/when this comes up again, I
> guess the process would be:
>
> - debugfs /dev/some-filesystem
> - debugfs: stat "some/problem/file"
> - get the inode number from the output above (867 in this case)
> - debugfs dump 867 inode867.bin
Actually, it's a bit more complicated than that. I should really add
a hook to debugfs to automate this, but... to find the block to grab,
you do this.
1) Grab the following fields from dumpe2fs (or debugfs's "stats" command)
Inodes per group: 8192
Block size: 4096
Inodes per group: 8192
Inode size: 256
2) To find out which block group the inode is located in, we calculate:
inode bg = inode_number / inodes_per_group
= 867 / 8192 = block group 0
(everything done using integer division, rounding any fraction down to 0.)
3) To find where the inode table for block group in question can be
found, check out dumpe2fs.
Group 0: (Blocks 0-32767) [ITABLE_ZEROED]
...
Inode table at 65-576 (+65)
^^^^^^
OK, we know it begins at block 65.
Now some more math:
inode_per_block = block_size / inode_size
= 4096 / 256 = 16
offset_block = (inode_number % inodes_per_group) / inodes_per_block
= (867 % 8192) / 16
= 54
So now we know that the block containing inode 867 is 65+54 = 119
Now to dump that block, we do:
dd if=/dev/fs-device of=block-119.dump bs=4k skip=119 count=1
> Or perhaps running e2fsck -n first to see which inodes really look
> corrupted and get the numbers that way.
Yep. In general, when you get corruption like this, the bad inodes
comes in chunks of 16 (if you are using 256 byte inodes) or 32 (if you
are using 128 byte inodes).
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
