On Sat, 17 Jul 1999, Greg Haerr wrote:
Actually, I have only studied the extent file systems, which are good for some
things (like performace on really big files and smaller files). For small
systems, these are not really suitable because they require too much caching,
esp for really small files. Under an OS like elks, this wastes a lot of space.
I probably should read about NTFS one day, but it sounds really complex (they
use B+ trees to store directory names). Such complexity is hard to do under
ELKS.
I choose the 1024 byte block becuase:
1) that is the size elks reads AFAIK when you read a buffer.
2) you have a reasonable area to store small files. For small files, this
removes an expensive seek on the hard drive. Most directories are small files,
and will save much time over separated inode/data fs's.
3) If i chose a smaller block size, there will be more overhead with the free
block bitmap, and i would probably need double indirect to store really large
files.
Later on, I will probably add an option to change the blocksize, but ATM, i am
still learning how to write the FS in elks :)
Oh, BTW, the inode numbers i chose for root/bad blocks is abitary and
unimportant to the outside world. (I think (I am still learning))
> : 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.
> :
>
> This is basically the BSD filesystem idea, right?
>
> : 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)
>
> 1K inodes are great for big operating systems, but may not
> be a good idea for small ones. Nonetheless, this is interesting, and is the
> same thing that NTFS uses. I presume you've read all the lit on NTFS,
> because it has some really neat ideas for a new fs design, which is what
> you're attempting.
>
>
> : 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.
>
> Why not swap the two and have the first inode be the root inode,
> just like now?
>
> It might be nice to have the 1k inode size configurable. It also
> would be nice to write a utility that would show what the average file size
> is on a minix or ext2 filesystem.
>
> Greg
