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.
>
> The NTFS filesystem is documented in a small thin book available
> at many bookstores in the US. I don't know about down under.
>
I may read up on it sometime :)
> :
> : 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.
>
> I think the 1k block size is fine.
>
> : : 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))
> :
> The inode number size *is* important, or the sys/stat.h structure
> has to change, causing all sorts of portability problems. Others may want
> to comment on this.
Why has elks chosen a 16 bit inode number for stat when the rest of the world
has 32 bit inode numbers? It probably is a good idea to use 32bit inode numbers.
Beau KUiper
[EMAIL PROTECTED]
