Latest Modification: May, 5th 1998
Conclusion: Behavior already implemented.
Currently inode blocks are not allocated at filesystem creation time. They are allocated as they are actually needed.
Conclusion: Implementation planned.
The current implementation of the make filesystem utility allocates all the space required for the ifile at filesystem creation time. Like the inode blocks, it would be sufficient to allocate blocks for the ifile on demand as they are used for the first time. The reason for the current (static) allocation scheme was that i wanted to avoid having to deal with an ifile that can have holes. However, it has turned out that dealing with an ifile with holes does not add very much complexity.
Conclusion: Keep a current maximum number of inodes.
Currently the number of inodes is fixed at filesystem creation time. It is possible to increase the number of inodes later (simply by enlarging the ifile, for example). However, this is not the same as not having a maximum number of inodes at all. But having a maximum number of inodes at all is required by current inode allocation algorithms that try to cluster file inodes near their directory inode and spread directory inodes across the available "inode space".
However, when using ext2 as a basis, the maximum number of inodes that one would like to have in a filesystemn is given by the total number of blocks in the filesystsem. But this might change when a tradfs is used that uses fragments or a totally different allocation scheme for small files (reiserfs maybe...)
Conclusion: Don't reserve the space for the inode blocks.
Most of the ext2 file systems I've checked out so far use <20% of the default number of inodes they have. So it would be a good idea not to allocate inode and ifile blocks that are not needed. However, it is possible to imagine a situation where the creation of a file fails because we cannot get space for the inode of that file. Is this an acceptible behaviour? (Currently I'd say yes, it is...)
Conclusion: Current (mk)dtfs implementation does not place inodes in a special file. I'll probably switch to having the inodes located directly in the ifile.
Instead of placing inodes in ifile blocks that are not part of any file, it would also be possible to place the inodes in a user-visible file (like the ifile or the segusage file.) This would even make the ifile unnecessary.
Pros of placing the inodes in a special file:
Cons of placing the inodes in a special file:
In ext2, for example, as implemented in the 2.0.x Linux kernels, the maximum file size is limited to 1GB (altough some people claim it is limited to 2GB...). Considering the fact that an ext2 inode needs 128 bytes of disk storage it turns out that only up to approx. 8 million inodes could be placed in such an inode file.
The default number of inodes in a file system as it is created by mkdtfs is determined by the number of filesystem blocks in the file system.
Assuming a block size of 4kb, 8 million inodes would limit the filesystem size to approx. 32 GB which is too low a limit to live with IMHO.
On the other hand it can be assumed that this limit will be removed from the ext2 file system in future versions. (Does it still exist in the 2.1.x kernel sources?)
However, we could have more than one inode file if we get into real troubles. On the other hand we could fix the ext2 file size problem. (Calculate the actual file size from the number of 512 byte blocks in the file. The current file size entry in the ext2 inode could indicate the number of bytes actually used in the last 512 byte block. Should be quite easy to implement.)
Conclusion: Currently not implemented, but I'll probably implement it.
Currently, no way of speeding up the location of free inodes has been specified for dtfs. Searching for a free inode by determining an approximate place for an inode to be created (based on the policy that file inodes should be placed somewhere near by the inode of the directory they belong to and directory inodes should be evenly distributed in the available "inode space") is probably too slow.
Using an inode allocation bitmap that is mapped in a special file (like the segusage file) would be one option. However, this bitmap could become inconsistent with the actual inode allocations.
But OTOH due to the transaction-like semantics of disk operations on dtfs, such an inconsistency can only arise
because when a checkpoint is written out we can be sure that both the dirty inode blocks and the inode bitmap file have already been written to disk.
Christian Czezatke, email: e9025461@student.tuwien.ac.at