mjhjmtu

The *nix filesystems maintain an inode table at the beginning of the disk (or at some fixed location). It is indexed by the inode number, which is an integer that uniquely identifies an inode. Knowing the inode number, an inode can be found quickly. The inode contains pointers/addresses to other disk blocks, which contains the actual data of the file.

I would like to know whether my approach below to get rid of the inode table and the inode number is efficient:

We still have inodes, but now, the inodes are stored in the data region of disk, and instead of keeping track of the inode number, we just record the disk address or block number of the inode. Whenever we try to access a file or its inode, we just use the disk address to find the inode, instead of indexing into the inode table using the inode number. This will save us from another layer of indirection.

What is missing in my approach? I would like to understand the rationale behind the inode table.

If I understand you correctly, you want to replace the inode number with the block address. That means (1) one inode per block, which wastes a lot of space (the inode isn't that large), and (2) it's not that different from using an inode number: An inode has a fixed size, so a block contains a known number n of inodes. So if you devide the inode number by n (which ideally is a power of two, so it's just a shift), the quotient is the block number of the inode (plus the disk address where the inode table starts), and the remainder is the index of the inode inside that block.

To understand the rationale behind the inode table, think about what data is stored in the inode table: It's attributes like owner, group, permissions and timestamps, and indices and indirect indices of the data blocks. You have to store those somewhere, and you can't store them together with the file data.

So if you want to design your own filesystem, the first question you have to answer is "how do I identify the data blocks that belong to a file?" and the second question is "where do I store attributes like ownership, permissions and timestamps?". And yes, you can use different schemes for that than inodes.

Edit

As for

why not just use its address, like we do with main memory and objects therein?

As I wrote, basically you have the block address - you'll just have to divide first, and add an offset. If you add the offset to every inode on principle, the "inode number" will be much larger, and you'll have a constant value in the high bits that's repeated in every inode number. This in turn will make each directory entry larger.

Don't forget that the unix filesystem was invented when harddisk sizes where around 20 Mbytes or so. You don't want to waste space, so you pack everything densely, and you avoid redundancy. Adding an offset every time you access an inode is cheap. Storing this offset as part of every "inode number" reference is expensive.

And the interesting thing is that even though the inode scheme it was invented for small harddisks in today's terms, it scales well, and even on harddisks in the terabyte range in "just works".