Filesystem questions

[Drogin]

I've been trying to read a little about filesystems and how harddisks work.
From what I can see so far, the BIOS access the Master Boot Record chosen, which will in turn run a startup binary code embedded in the MBR. This launch a chosen OS to start, which will require more binaries located in one of the partitions at the disk.
The partitions are avaiable to the MBR, because the MBR stores pointers to the various partitions.
Now, before any more files can be accessed, the superblock of the partition will be read.
Am I right so far?

If I am basically right so far, here is what I don't understand:
What's the connection between the Inodes and the Super-Block?
I mean..say you wanna access the file that inode nr#10293 points to.
How would the filesystem find inode nr#10293?
Does the superblock contain some kind of global inode-table?

EDIT:
Oh yeah, and I'm talking about the ext3 filesystem

[matsp]

I think, in general, the boot process goes as follows:
Read MBR
MBR contains code to read some other blocks from the disk.
These sectors contain enough file-system code to know how to load enough of the boot code to decode the file-system. That may involve some fixed position files, or simply a list of sectors stored by the boot manager.

--
Mats

[Drogin]

Ah, thanks

But how about the inodes? I mean, there's bound to be quite a large number of them.
How does the filesystem know where the inode they are looking for are stored?

Does the superblock of one filesystem keep an inode-table?
Or how does the system find an arbitrary inode? Does it scan through the whole disk untill it finds the correct inode?

Under the ext2-article, Wikipedia states:

The space in ext2 is split up in blocks, and organized into block groups, analogous to cylinder groups in the Unix File System. This is done to reduce external fragmentation and minimize the number of disk seeks when reading a large amount of consecutive data.

Each block group may contain a copy of the superblock and block group descriptor table, and all block groups contain a block bitmap, an inode bitmap, an inode table and followed by the actual data blocks.

The superblock contains important information that is crucial to the booting of the operating system, thus backup copies are made in multiple block groups in the file system. However, typically only the first copy of it, which is found at the first block of the file system, is used in the booting.

The group descriptor stores the location of the block bitmap, inode bitmap and the start of the inode table for every block group and these, in turn are stored in a group descriptor table.

But in the inode-article, it states:

The inode number indexes a table of inodes in a known location on the device; from the inode number, the kernel can access the contents of the inode, including the data pointers, and so the contents of the file.

So I get the impression wikipedia states in quote1 that the inodes are spread all throughout the disk, and in quote2, that they are stored at a specific location. I think I'm just having serious trouble visualizing how the connection between kernel, the inodes, and the location of the inodes on the disk, work.

[matsp]

The superblock will contain a inode to block table (or something like that, depending on the exact type of filesystem). So to find the block for inode 1234, we look at index 1234 in the the table. It holds the block number, which is then used to find the actual data.

--
Mats

[brewbuck]

So I get the impression wikipedia states in quote1 that the inodes are spread all throughout the disk, and in quote2, that they are stored at a specific location. I think I'm just having serious trouble visualizing how the connection between kernel, the inodes, and the location of the inodes on the disk, work.

Both statements are correct. There is more than one inode table. Given an inode number, you can compute which table the inode is in, as well as the offset within the table. This is sort of like virtual paging where address translation happens in multiple stages.

Spreading the inode tables across the disk serves a few purposes. First, it improves performance because you can keep file data close to the inode representing that file (if all the inodes were in a single spot on the disk, most file data would be very far away from the inode, and updates to the inode would involve a lot of seeking). Second, it makes it more likely that data can be recovered in the event of a media failure which might only affect a localized portion of the disk. A local failure which wipes out a monolithic inode table would effectively render the entire filesystem unrecoverable