Ok, problem.
Defragmentation is _very_ difficult, if you move a file you'll have to
renumber the inode, nasty for files with multiple links.
If you use aligned allocation, as you've got a free blocks bitmap it's
easy, you should be able to avoid the need for defragmentation.
Next a suggestion, I think it'd be a good idea to put a magic number at
the start of an inode, that way 'lost clusters' can be checked for file
inodes easily and reattached to lost+found if sane.
I notice that you've not mentioned how the end of the filesystem is
marked, you do need this as the filesystem image may be copied to a new
larger device. In fact it'd be nice if you recorded only the higest
block that has actually been written to, that way if the filesystem is
copied to a larger device it will _automatically_ extend to fill the
device. (really neat with /dev/md devices :-) ) Unfortunatly to shrink
a filesystem you'd need to solve the defragmentation problem.
I know 64Mb (actually I'd estimate about 60Mb after the inode info is
allocated) is more than enough, but you should _specify_ triple indirect
and possibly larger. Who knows you may want to copy a CDROM one day. :-)
Compression/encoding: specify hooks and data space for things like
compression, forward error correction and encryption. (eg encoding
method field and lseek translation table pointer)
The final things you might want to consider are journeling and other
"new features people will want for V2"
--
Rob. (Robert de Bath <http://poboxes.com/rdebath>)
<rdebath @ poboxes.com> <http://www.cix.co.uk/~mayday>
On Fri, 16 Jul 1999, Beau Kuiper wrote:
> 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]
>
>
