next up previous
Next: Conclusion Up: Future Work Previous: 64 bit block devices


Extensible Inode Table

Adding an dynamically extensible inode table is something that has been discussed extensively by ext2/3 developers, and the issues that make adding this feature difficult have been discussed before in [15]. Quickly summarized, the problem is a number of conflicting requirements:

Most obvious solutions will violate one or more of the above requirements. There is a clever solution that can solve the problem, however, by using the space counting backwards from 13#13, or ``negative'' inode. Since the number of block groups is limited by 14#14, and since the maximum number of inodes per block group is also the same as the maximum number of blocks per block group is 15#15, and if inode numbers and block numbers are both 32-bit integers, then the number of inodes per block group in the ``negative'' inode space is simply 15#15 - normal-inodes-per-blockgroup. The location of the inode blocks in the negative inode space are stored in a reserved inode.

This particular scheme is not perfect, however, since it is not extensible to support 64 bit block numbers unless inode numbers are also extended to 64 bits. Unfortunately, this is not so easy, since on 32-bit platforms, the Linux kernel's internal inode number is 32 bits. Worse yet, the ino_t type in the stat structure is also 32 bits. Still, for filesystems that are utilizing the traditional 32 bit block numbers, this is still doable.

Is it worth it to make the inode table extensible? Well, there are a number of reasons why an extensible inode table is interesting. Historically, administrators and the mke2fs program have always over-allocated the number of inodes, since the number of inodes can not be increased after the filesystem has been formatted, and if all of the inodes have been exhausted, no additional files can be created even if there is plenty of free space in the filesystem. As inodes get larger in order to accommodate the EA-in-inode feature, the overhead of over-allocating inodes becomes significant. Therefore, being able to initially allocate a smaller number of inodes and adding more inodes later as needed is less wasteful of disk space. A smaller number of initial inodes also makes the the initial mke2fs takes less time, as well as speeding up the e2fsck time.

On the other hand, there are a number of disadvantages of an extensible inode table. First, the ``negative'' inode space introduces quite a bit of complexity to the inode allocation and read/write functions. Second, as mentioned earlier, it is not easily extensible to filesystems that implement the proposed 64-bit block number extension. Finally, the filesystem becomes more fragile, since if the reserved inode that describes the location of the ``negative'' inode space is corrupted, the location of all of the extended inodes could be lost.

So will extensible inode tables ultimately be implemented? Ultimately, this will depend on whether an ext2/3 developer believes that it is worth implementing -- whether someone considers extensible inode an ``itch that they wish to scratch''. The authors believe that the benefits of this feature only slightly outweigh the costs, but perhaps not by enough to be worth implementing this feature. Still, this view is not unanimously held, and only time will tell.


next up previous
Next: Conclusion Up: Future Work Previous: 64 bit block devices
Mingming Cao 2005-07-26