I have a design decision to make in Punix. I'm still writing the filesystem code, and at this point I'm trying to decide how big to make an inode as
stored on FlashROM. For those who are not familiar with inodes, they are the file header that contains at least the following information in Un*x:
In the FlashROM, each block number is only 2 bytes because blocks are 128 bytes big, and FlashROM is 2MB (at most 16,384 blocks).
The inode can be up to 128 bytes, which is plenty large, but larger inodes means more overhead. For example, with 10 files, this corresponds to up to 1280 bytes of overhead for just the inodes themselves. If inodes are only 32 bytes big, this is only 320 bytes of overhead. The only adjustable field size is NDADDR, or the number of direct blocks in the block index table. With 4 direct block numbers, the inode is 32 bytes (so 4 can fit in a block). With 20, the inode is 64 bytes. And with 52 direct block indexes, the inode is 128 bytes. That would be overkill, though.
Basically what I'm trying to figure out here is how to optimize FlashROM storage space. With 4 direct block numbers, an inode is only 32 bytes, but this means that any file larger than 512 bytes (4 * 128 bytes per block) will need to use an indirect block, translating into more overhead. On the other hand, with 20 direct block numbers, the inode is 64 bytes, so any file larger than 2560 bytes (20 * 128) will need to use an indirect block. If there are a lot of "small" files (512 bytes or less), 32 byte inodes would be optimal. But if there are a lot of "medium" size files (between 513 and 2560 bytes), 64 byte inodes might be better. (The relative overhead of the inode and indirect blocks diminish as file size increases, so I won't consider "large" files).
A similar but lesser consideration is symbolic links. If a symlink pathname is short it is stored where the block index tables are normally stored, but if it's too long to fit there, other blocks are used to store the name (like a regular file). With a 32 byte inode, the inode can store names up to 14 characters long (no trailing NUL character), but a 64-byte inode can fit up to 46 characters. Since there probably won't be a lot of symlinks longer than 14 characters (or very many symlinks, period) in a Punix system, this shouldn't matter much.
Now to the real question:
What type of file size patterns does everyone see on their calculators? Are 0-512 byte files more common than 513-2560 byte files, or the opposite?
- mode and type of file (2 bytes)
- number of links to file (1 byte)
- file size (number of bytes in file) (3 bytes)
- owner's user id (2 bytes)
- owner's group id (2 bytes)
- time last accessed (NOTE: this will probably not be stored on the Punix File System, instead it may have a feature similar to "relatime" and just set a flag, possibly in the "mode" field, when atime >= max(ctime,mtime))
- time last modified (4 bytes)
- time last changed (4 bytes)
- direct block index table (NDADDR * 2 bytes)
- indirect block index table (3 indirect blocks) (3*2 = 6 bytes)
In the FlashROM, each block number is only 2 bytes because blocks are 128 bytes big, and FlashROM is 2MB (at most 16,384 blocks).
The inode can be up to 128 bytes, which is plenty large, but larger inodes means more overhead. For example, with 10 files, this corresponds to up to 1280 bytes of overhead for just the inodes themselves. If inodes are only 32 bytes big, this is only 320 bytes of overhead. The only adjustable field size is NDADDR, or the number of direct blocks in the block index table. With 4 direct block numbers, the inode is 32 bytes (so 4 can fit in a block). With 20, the inode is 64 bytes. And with 52 direct block indexes, the inode is 128 bytes. That would be overkill, though.
Basically what I'm trying to figure out here is how to optimize FlashROM storage space. With 4 direct block numbers, an inode is only 32 bytes, but this means that any file larger than 512 bytes (4 * 128 bytes per block) will need to use an indirect block, translating into more overhead. On the other hand, with 20 direct block numbers, the inode is 64 bytes, so any file larger than 2560 bytes (20 * 128) will need to use an indirect block. If there are a lot of "small" files (512 bytes or less), 32 byte inodes would be optimal. But if there are a lot of "medium" size files (between 513 and 2560 bytes), 64 byte inodes might be better. (The relative overhead of the inode and indirect blocks diminish as file size increases, so I won't consider "large" files).
A similar but lesser consideration is symbolic links. If a symlink pathname is short it is stored where the block index tables are normally stored, but if it's too long to fit there, other blocks are used to store the name (like a regular file). With a 32 byte inode, the inode can store names up to 14 characters long (no trailing NUL character), but a 64-byte inode can fit up to 46 characters. Since there probably won't be a lot of symlinks longer than 14 characters (or very many symlinks, period) in a Punix system, this shouldn't matter much.
Now to the real question:
What type of file size patterns does everyone see on their calculators? Are 0-512 byte files more common than 513-2560 byte files, or the opposite?
