Review the Avalon 1.0 Filesystem

[Unwritten Axiom]

I just finished writing out documentation for the Avalon 1.0 filesystem. I'm planning to use this as the filesystem for my OS (Avalon). I haven't actually tested it yet, but I plan on doing so within the next few weeks.

http://www.freewebs.com/euxenium/Documents/Avalon%201.0%20Filesystem%20Specification.html

If you notice any spelling mistakes or grammatical errors, please let me know.
Any questions or comments would really help me improve the filesystem.

Feel free to use the filesystem in your OS projects, but be sure to follow the document exactly. I wouldn't recommend implementing the 1.0 filesystem because it hasn't really been tested and may have some problems. If you do decide to use the filesystem, and want to improve it, please email me first with your idea. I'd like to keep it as clean, organized, and well documented as possible, and adding custom extensions would only push it in the opposite direction.

There currently isn't any journaling or security, and I don't plan on implementing things like that in version 1.0.

Any suggestions are welcome.

[emilsoft]

Nice! I'm also starting my own OS Project and I couldn't makeup my mind on which FileSystem to use. If I can't get FAT/FAT16/32 to work, then maybe I'll use yours.

[Pype.Clicker]

this is an interresting summary of a basic (for tutorial purpose) file system. Be sure your allocation policy will allow "runs" large enough to be allocated, because this will be the critical point for memory consumption or file-seeking algorithms.

A lot of good filesystem use an index on the "runs/sector list", so that if you're looking for the x'th sector and that the sector list is splitted among N "parallel inode" (i would have called these "inode extension sectors" instead), you can know in which one the extensions sectors you will find the info by looking the extensions index in the "inode master sector" (thus reducing the amount of head displacement and I/O transfers)

Also, i think you should try to split your "bitmap table" across the disk so that allocating sector i can be done without moving the head back to sector 0x0A+i/512, modifying the bitmap, moving to sector i and then using it. Some filesystems like EXT2 explicitly splits the bitmap, making each "cylinder" holding the cylinder's own bitmap. NTFS doesn't explicitly do this, but their bitmap is a file that can be fragmented, so if i were a MS-software designer, i would make the NTFS formatter scatter the bitmap file across the disk for better performance and noone could notice it by looking at the FS' technical specs.

[Unwritten Axiom]

I've been testing and have come to the conclusion that v1.0 has some major problems with byte ordering, etc. that make the document incorrect. Do NOT use v1.0 to implement the filesystem. I'm testing v1.0 now and fixing any bugs that come up. I'll release it as v1.01 as soon as I get a working model up and running. It'll also include an image of a floppy disk formatted with the filesystem.

Pype: Those are some very good ideas that I'm taking into consideration for 1.01.