Reading files from ext2?

[glauxosdev]

I loaded the superblock from sectors 2 and 3 and I saved block size in sectors (2 << field found in superblock)
Also, I got number of blocks and inodes in each group.
For now, how do I calculate at which physical sector inode 2 resides?

Next, we have to determine which block contains our inode. This is achieved from:

containing block = (index * INODE_SIZE) / BLOCK_SIZE

where INODE_SIZE is either fixed at 128 if VERSION < 1 or defined by a field in the Superblock if VERSION >= 1.0, and BLOCK_SIZE is defined by a field in the Superblock.

I don't understand which block does it mean. I doubt it is the physical one.

Has anybody any ideas?

Regards,
glauxosdev

[madanra]

Just above the bit you quoted, it says:

Once we know which group an inode resides in, we can look up the actual inode by first retrieving that block group's inode table's starting address (see Block Group Descriptor above).

So the start address of the inode table is given in the Block Group Descriptor.

[glauxosdev]

Sorry, I was a bit unclear.
I meant: How do we calculate at which physical sector does block group descriptor reside?

[madanra]

The block group descriptor table immediately follow the superblock.

[glauxosdev]

Sorry again, but what about the physical address of block group containing inode 2?
I'm tired and I can't concentrate at anything, that's why I was unable ask my question properly.

Regards,
glauxosdev

[madanra]

That information is in the block group descriptor table, as I said.

[iansjack]

I think you should read this document rather than relying just upon the wiki: http://www.nongnu.org/ext2-doc/ext2.html . It tells you everything you need to know.

[glauxosdev]

Using this document and my hex editor, I can find (I hope ) data of inode 2, which is the root directory entry. if I am not mistaken.
But after that my ext2 formatted stick and the document don't agree.
The document says that filename starts at byte 9th (the interesting thing is that this information is followed by a "?").
But in my hex dump I see no filename there.
Instead I see "lost+found" at offset 32 from directory entry, and "system" (the directory I want to look) at offset 92.
After the last filename I see only null bytes.
So I wonder, what are those bytes there between the filenames, and before them?

@Iansjack: I had already found that document and it looked complicated.

[iansjack]

Look at your directory again, bearing in mind the following:

The first entry will be for a directory called ".".
The second entry will be for a directory called "..".
After that there is (possibly) the Indexed Directory Root Information Structure.
The third entry will be for a directory called "lost+found".
The fourth entry will be for your directory "system" (assuming that's the first of your files on the disk).

I had already found that document and it looked complicated.

Well, it's not a trivially simple subject. Wait until you get to writing files and working out the trebly-indirect blocks; the calculations will make your head hurt. And then there's all the metadata that needs to be updated.

Nobody said it was going to be easy.

[glauxosdev]

Ok, I found the "4.1.6. Sample Dir" section, and from my hex editor I see that my directory resides in inode 1FC1h. I can find it at offset 2040400h. What are the calculations between those two values?
I don't undestand exactly how we determine which physical sector contains that inode.
(Wiki's article seems to overcomplicate this? Or is this issue even more complicated?)

Regards,
glauxosdev

[iansjack]

I have to refer you again to the document I linked to. It contains all the information that you need and gives details of all the structures that describe the file system. Very briefly, to locate the information in a file (or directory):

1. Read the directory entry for the file. From this you find its associated inode number.

2. Read that inode from the array of inodes.

3. Read the entry in the inode listing the first data block of the file.

4. Convert that blockno to an offset (a trivial calculation since you know where the first data block is and how many bytes there are in a block).

5. Read the block from the disk; you now have the first BLOCKSIZE bytes of the file.

6. Repeat 3 - 5 for the remaining data blocks. The only complication here is that above a certain number you have to deal with indirect pointers, then (possibly) doubly- and triply-indirect pointers.

You have to read that document and understand what the structures, such as the superblock, are telling you. And reading a file, where you aren't changing anything on the disk, is trivial compared to creating a new one and writing to it as you then have all sorts of housekeeping to take care of.

[glauxosdev]

Hi,

Based on your advice and various documents, I wrote some code but it just doesn't load the kernel. I searched for sample ext2 bootsectors just to borrow some ideas, but I found nothing relevant. I have found bootsectors for fat12 and grub, which is for partitioned disks (if I am not mistaken). Edit: I was mistaken.
Could you point me to a ext2 bootsector? I promise, I will not copy-paste, I will just get some ideas.

Regards,
glauxosdev

[iansjack]

I'm afraid that I can't help you there. With a boot sector you only have 512 bytes to play with so you have to be pretty adept at assembler programming, and thoroughly understand the file system, if you want to cram a program that can read an arbitrary file from an ext2 file system into that space. Most boot loaders will use the boot sector to load a second-stage loader from a known location. That will have more space to play with and will be able to load the kernel from the file system. Personally I am of the school of thought that says there are plenty of good bootloaders (e.g. GRUB) already, so why reinvent the wheel. But perhaps you have a particular interest in bootloaders.

I'd gauge that your current problem is that you don't understand the file system enough to do this. So what I would suggest is that you write a user program to read an ext2 file system from a disk image file. That way you will be able to write the code in C and use a debugger to step through it and inspect the value of variables to see that you are reading the right information. Play with that until you understand the file system well enough for your purposes. Then, and only then, you may be able to write a bootloader in assembler; but I still think you'll have a hard time fitting it into 512 bytes.

Do you have a particular aversion to using GRUB?

Of course, later you will no doubt want to write a full-blown filesystem handler. My recommendation would be to use a higher-level language, such as C, rather than assembler, but it's up to you. But whatever language you choose you need to really understand how the filesystem works before you can complete the task.

[glauxosdev]

Most boot loaders will use the boot sector to load a second-stage loader from a known location.

How do we know that known location?

But perhaps you have a particular interest in bootloaders.

I just want to make an OS from start to finish.

That way you will be able to write the code in C

I write all of my OS in assembly.

Do you have a particular aversion to using GRUB?

Simply by design as I explained already.

I still think you'll have a hard time fitting it into 512 bytes

That's almost right, actually they are 510 bytes.

Ok, I will try to understand the filesystem better, but I will not bother loading from a known location. It's just pointless. Why even MikeOS loads then its kernel from fat12 and not from a known location? Yes, I know fat12 is simpler than ext2.

Regards,
glauxosdev

[madanra]

In an ext2 partition, you have 1024 bytes for the bootloader, as the superblock doesn't start until 1024 bytes in. Of course, the MBR will probably only load the first 512 bytes, so you have to load the second 512 bytes yourself. Once you have 1024 bytes to play with, that is definitely enough to read a file from ext2; I have written such a bootloader, with pretty comprehensive error checking. That does require significant hand optimisation of the assembly to save space though. You can write it in considerably less space if you simply read inode 5 (reserved for a second-stage bootloader) rather than having to read the root directory and parse the directory structure.