ext2 inode table does not seem to be pointing to correct block
by gglq000 from LinuxQuestions.org on (#5C21W)
Hi all, topic of this post does not exactly align it is about file system (ext2) question but looking through all other sub-threads, i think "Linux - Enterprise" may be best fit since it is more of an adv. topic.
Here is the story, I brushed up with my ext file system structure knowledge and needed to code to locate arbitrary file from /dev/sda1's root directory. File name is boot.bin.
So good place to start is from superblock. The /dev/sda1 in this case is about 5G volume with only primary partition formatted with ext2.
dumpe2fs /dev/sda1 shows first group block's following info:
block size: 4096
inode table start: 323 (th block)
first inode 11.
I found through stat boot.bin that inode No. is 0xC (12d) and zeroed onto inode's entry in the inode table as following:
hexdump -C /dev/sda/ -n 512 -s $((323 * 4096)) = 0x143100.
Since it is 12th inode, and located boot.bin's inode at 0x143100
..
00143100 ed 41 00 00 00 10 00 00 50 0e e4 5f ed ff e3 5f |.A......P.._..._|
00143110 ed ff e3 5f 00 00 00 00 00 00 03 00 08 00 00 00 |..._............|
00143120 00 00 00 00 03 00 00 00 43 03 00 00 00 00 00 00 |........C.......|
00143130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
Here, couple of checks look at i.e. No. of blocks=8 dates etc, but at 0x28th offset the block address shows 43 03 00 00 which is 0x334 corresponding to 825th block?
When I dump that it does not show the boot.bin's file content at all:
hexdump -C /dev/sda1 -n 4096 -s $((835*4096))
00343000 02 00 00 00 0c 00 01 02 2e 00 00 00 02 00 00 00 |................|
00343010 0c 00 02 02 2e 2e 00 00 0b 00 00 00 14 00 0a 02 |................|
00343020 6c 6f 73 74 2b 66 6f 75 6e 64 00 00 0c 00 00 00 |lost+found......|
00343030 d4 0f 08 01 62 6f 6f 74 2e 62 69 6e 0d 00 00 00 |....boot.bin....|
00343040 c4 0f 0d 01 2e 62 6f 6f 74 2e 62 69 6e 2e 73 77 |.....boot.bin.sw|
00343050 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |p...............|
00343060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
I can't discern why because stat of boot.bin from debugfs shows blocks being used 8 and 1st block is 1029 vs. 835 which is what its inode table points to?
However if I use stat's output to dump 1029th block, then yes it prints out the boot.bin's content exactly:
# hexdump -C /dev/sda -n 4096 -s $((1029*4096)):
00405000 0a 38 38 37 37 36 36 35 35 34 34 33 33 32 32 31 |.887766554433221|
00405010 31 38 38 37 37 36 36 35 35 34 34 33 33 32 32 31 |1887766554433221|
Conclusion is, of all those, everything makes sense except boot.bin's inode table entry just pointing to 835th block vs actual block is 1029th block.
Can anyone see what I am looking wrong at???
THanks.,


Here is the story, I brushed up with my ext file system structure knowledge and needed to code to locate arbitrary file from /dev/sda1's root directory. File name is boot.bin.
So good place to start is from superblock. The /dev/sda1 in this case is about 5G volume with only primary partition formatted with ext2.
dumpe2fs /dev/sda1 shows first group block's following info:
block size: 4096
inode table start: 323 (th block)
first inode 11.
I found through stat boot.bin that inode No. is 0xC (12d) and zeroed onto inode's entry in the inode table as following:
hexdump -C /dev/sda/ -n 512 -s $((323 * 4096)) = 0x143100.
Since it is 12th inode, and located boot.bin's inode at 0x143100
..
00143100 ed 41 00 00 00 10 00 00 50 0e e4 5f ed ff e3 5f |.A......P.._..._|
00143110 ed ff e3 5f 00 00 00 00 00 00 03 00 08 00 00 00 |..._............|
00143120 00 00 00 00 03 00 00 00 43 03 00 00 00 00 00 00 |........C.......|
00143130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
Here, couple of checks look at i.e. No. of blocks=8 dates etc, but at 0x28th offset the block address shows 43 03 00 00 which is 0x334 corresponding to 825th block?
When I dump that it does not show the boot.bin's file content at all:
hexdump -C /dev/sda1 -n 4096 -s $((835*4096))
00343000 02 00 00 00 0c 00 01 02 2e 00 00 00 02 00 00 00 |................|
00343010 0c 00 02 02 2e 2e 00 00 0b 00 00 00 14 00 0a 02 |................|
00343020 6c 6f 73 74 2b 66 6f 75 6e 64 00 00 0c 00 00 00 |lost+found......|
00343030 d4 0f 08 01 62 6f 6f 74 2e 62 69 6e 0d 00 00 00 |....boot.bin....|
00343040 c4 0f 0d 01 2e 62 6f 6f 74 2e 62 69 6e 2e 73 77 |.....boot.bin.sw|
00343050 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |p...............|
00343060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
I can't discern why because stat of boot.bin from debugfs shows blocks being used 8 and 1st block is 1029 vs. 835 which is what its inode table points to?
However if I use stat's output to dump 1029th block, then yes it prints out the boot.bin's content exactly:
# hexdump -C /dev/sda -n 4096 -s $((1029*4096)):
00405000 0a 38 38 37 37 36 36 35 35 34 34 33 33 32 32 31 |.887766554433221|
00405010 31 38 38 37 37 36 36 35 35 34 34 33 33 32 32 31 |1887766554433221|
Conclusion is, of all those, everything makes sense except boot.bin's inode table entry just pointing to 835th block vs actual block is 1029th block.
Can anyone see what I am looking wrong at???
THanks.,