Ext2 implementation problem [SOLVED]

[gerenjo]

Hello,

I am currently trying to implement ext2 in my OS. I made an image of an ext2 hdd and made up some directories and put random files in them. Now, before I put bad code in my kernel, I made a small program that is supposed to run through the whole filesystem, to fully understand the filesystem.
But I have a problem : here is my filesystem
/dir1/
/dir1/file1
/dir1/file2
/dir1/sub1/
/dir1/sub1/file1
/dir2/.hidden_file
/dir2/symlink1

Now I run my test program on that image, and here is my output:
1264 inodes per block
Listing /
-> . : name_len = 1, type = 2, inode = 2, next = 12
-> .. : name_len = 2, type = 2, inode = 2, next = 32
-> dir1 : name_len = 4, type = 2, inode = 1265, next = 12
-------> . : name_len = 1, type = 2, inode = 1265, next = 12
-------> .. : name_len = 2, type = 2, inode = 2, next = 12
-------> file1 : name_len = 5, type = 1, inode = 1268, rec_len = 13
-------> file2 : name_len = 5, type = 1, inode = 1269, rec_len = 13
-------> sub : name_len = 3, type = 2, inode = 12, next = 952
-> dir2 : name_len = 4, type = 2, inode = 1266, next = 968

As you can see, the superblock tells me that there are 1264 inodes per group. But when I read the inode of dir1/, I see inode 1265. I thought that it might mean that the content of dir1 has been put in the second block group. So I made some division/modulo, and succeeded in reading the content of dir1/, its inode being indeed the 1st of the second group. But now I can't see why dir2/ is not shown, even if I read the group2 / inode 2 (which is actually group[1], inode[1] of course).
It seems I have the same problem for reading dir1/sub/, located at inode 12... But is it inode 12 of the 1st group ? Or the 2nd one ? If it is the 12th of the second one, does it mean that directories can contain inodes pointers that point to an other group's inodes, but only if this group is after the current one ? This seems quite strange to me, isn't it ? In other words, How is this cross-group reference thing working ?

Thanks for any help,

Lionel

Edit: made the hierarchy clearer
Edit2 : Fixed, thanks a lot James.

[jal]

Have you tried making a hex dump of the file system to check whether you can find the things that are missing? That might lead you to some bugs or misassumptions in your code.


JAL

[JamesM]

Hi,

The inode number given is absolute. To calculate which block group and offset an inode is in from its inode number, you:

* Decrease the inode number by 1. Inode 0 is invalid and is never used, and because of this ext2 shunts all inode numbers down by one to get one more inode out of the system. But you of course know this as you're managing to read the root directory.

* The block group of the modified inode is the integer division of the inode number by the number of inodes per group, the offset is the modulo, thus:

Code: Select all

    uint32_t index = inode % LITTLE_TO_HOST32(m_Superblock.s_inodes_per_group);
    uint32_t group = inode / LITTLE_TO_HOST32(m_Superblock.s_inodes_per_group);

Also note that the inode table may extend onto multiple data blocks, so you may have to so some extra calculation to get the correct block number to read and offset.

Cheers,

James

EDIT: There's the little-known tool "debugfs" that comes with ext2fstools - run that and discover a world of debugging joy.

[gerenjo]

Also note that the inode table may extend onto multiple data blocks, so you may have to so some extra calculation to get the correct block number to read and offset.

That was indeed the problem. I was reading the right block, but not the right offset in the block I was reading if this was not the first block of the inode table because of crappy test code . Thanks for the precision about the inode number and the debugging tool !

Lionel