Hi again,
I am working with the elks source and I am creating a new filesystem and would
love some feedback on its design. It has the following properties:
1) All blocks are 1024 bytes in size.
2) the first 8K is managed as follows
1st 512 byte sector is solely used for a boot sector to load 7K bootup manager
of choice. This is good because the sys program doens't have to worry about
trashing the superblock as it installs the bootup manager of choice :)
2nd 512 byte sector is the superblock. The data in the superblock can be
recreated if needed, so copies of it arn't required.
the next 7 blocks (7K) is the boot manager.
3) The rest of the space is divided up into zones, each containing a maximum of
65536 blocks.
4) The first 8K of each zone is a bitmap of free blocks in the zone, 1 for
used, 0 for free.
5) The rest of the zone is used for storing inodes/files.
6) Inodes are stored in exactly the same areas of file data and are 1024 bytes
in size.
7) For files < 1000 bytes in size (often dirs, symbolic links, many small
files), the data is directly stored after the inode (great performace boost
IMHO)
8) For files > 1000 bytes, that space in the inode is used to point to blocks
the data is really stored in. This allows files up to 256000 bytes to be
stored, and offers decent performace.
9) For files > 256000 bytes, that space is used to store pointers to blocks
containing further pointers to blocks that store the data (indirect). This
allows files up to the size of 65536000 bytes (64M) which should be more than
enough :).
10) Inode numbers are really a combination of the zone and block. (32 bit
number. High 16 bit is zone, low 16 bit is block). This allows file references
to be picked up quickly.
11) Directores work like they do under ext2. This allows long fille names :)
12) The first inode will be a bad block inode that stores bad blocks. The
second will be the root inode.
That is about it for now. Please give me comments about the robustness,
performace, memory usage, ect.
Beau Kuiper
[EMAIL PROTECTED]
