: 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 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.
Greg
