![]() Page tables work differently because hardware implements them differently - that's just how it is. So there must be some form of indirection. You can't do that if every inode has a different size. Just adding a variable number of block pointers to the inode is not practical, because the inode must take up a fixed amount of space - you want to use the inode number to calculate the block address and the offset inside the block where the inode information is stored. As you say yourself, everything has to be stored somewhere, and if it doesn't use up space at location X, it will use up space at location Y. It's not about somehow saving space in total. So data block size can't "decrease".Īs I tried to describe above, the whole point of having the inodes not use up too much space is to make inode access faster (or, alternatively, make caching inodes use up less memory - back then when the unix file system with inodes was invented, computers had a lot less memory than today). Page tables on the other hand work very differently.ĭata blocks are of fixed sizes (originally 512 bytes, IIRC), which is a multiple of the block size of the underlying harddisks. many small files, some larger files, and very few huge files". So the point is not "use up less space in total", but "use a scheme that uses blocks efficiently for the expected distribution a files wrt. So you use a two-level indirect block: You just add one pointer to the inode, then you have a whole block to store pointers to indirect blocks, and the indirect blocks store the block address of the file itself.Īnd so on, you can add higher-level indirect blocks, or stop at some stage, until you reach the maximal size of a file possible with the structure you want. And you want small inodes, so as many as possible inodes can fit into a single block (less disk access to read more inodes). This doesn't use somehow "less space", and most filesystems, even early ones, worked like that (have a pointer near the inode/filename which points to a block, which stores the block numbers of the file).īut what do you do when the space in this block runs out? You have to allocate another block, but where do you store the reference to this block? You could just add those references to the inode, but to store largers files, the inode would get large. Only the address of this indirect block is stored in the inode. The next level is one indirection: You allocate a block to store the block pointers. This means you use a few bytes more for the inode, but for small files, you don't have to allocate a complete block, which is mostly empty. You can store one or a few block numbers directly in the inode. ![]() The original hierarchy of the inodes levels works roughly like this: ![]()
0 Comments
Leave a Reply. |