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.,

If it's the 12th inode, and inode table starts at 323th block, shouldn't you seek to 323*4096+11*inode_size=0x143B00? (if inode_size=256)

I mean inode 1 is the bad blocks inode, inode 2 is the root directory inode (which is probably what you were seeing above), and so on. I don't remember what the rest of them are for, but the first ten inodes are special. Inode 11 is the first non-reserved inode.

Yup, not sure why I did not think about it before it works now, thanks!!!

# hexdump -C sda1.bin -n 4096 -s $((323*4096+11*256))
00143b00 a4 81 00 00 21 00 00 00 72 2e e4 5f 92 19 e4 5f |....!...r.._..._|
00143b10 92 19 e4 5f 00 00 00 00 00 00 01 00 08 00 00 00 |..._............|
00143b20 00 00 00 00 01 00 00 00 05 04 00 00 00 00 00 00 |................|
00143b30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

# hexdump -C sda1.bin -n 512 -s $((0x405*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|
00405020 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |1...............|
00405030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|