Currently icheck only shows the (block and) inode number:
debugfs: icheck 9727060
Block Inode number
9727060 34835
With ncheck you can then find a path to the file, but you have no idea what position in the file the block is at.
icheck has to iterate the blocks for the inode, so i think keeping track of the block number / file position wouldn't be too hard.
Assuming the block is the 20th block of the file (at position 77824), icheck would then output something like:
debugfs: icheck 9727060
Block Inode number Block offset
9727060 34835 19
In case you're wondering what's the use-case: I have a raid5 that has some mismatches - that is, some data has been silently corrupted and the data and the parity don't agree. I have the checksum for the offending file, so I can try fixing it if I know where in the file the problem is. It would be nice if debugfs could give that information directly, since it already scans the blocks anyway.
I don't have enough knowledge about ext2/3/4 to do this myself - I could probably get it working for myself, but it would probably break horribly on files with holes or other features I have never even heard of. I tried looking at the code in the hopes that the file position was already tracked and just needed printing, but it seemed that ext2fs_block_iterate3 only keeps track of the position inside the currently iterated indirect block.
I do have a small python script I can use to handle my current problem, since the file in question shouldn't have holes or anything fancy, but this would be a really nice feature to have in debugfs.