OSDev.org

I have designed a new filesystem, TFS. It is designed to be flexible, and to be implemented easily (like, very easily, I found).
It's basic workings include a variable index entry size, with slightly differing specs for each size (this allows one to create implementations very easily, as you can chose the level of complexity). Also, one of these index entry sizes (256) allows for storing file information directly inside the entry. There is no fragmentation support. Each index entry points to it's parent index entry, based on a simple static number assignment system. The first entry is 0 (root), the second is 2. This isn't based on creation order, but actual order on the disk.

This file system is loosely based upon SFS (mostly, the superblock format, and a couple other things), with permissions i got from the Ext2 entry on the wiki

This Filesystem also supports unix permissions, time stamps, user stuff, etc.

Index Entry sizes are as follows:
64 bytes - Basic file info (type, name, starting block in data area, length, and pointer to parent)
128 bytes - The above + Permissions, time, user stuff, OS ID, pointer to continuation entry (extra long file names). This entry also supports longer filenames than 64 bytes, even without a continuation.
256 bytes - Allows for everything above + storing 127 bytes of the file data in the entry.
Now, you may make the entry size above 256 (actually, the only other option is 512) and that can be used for whatever.
Less than 64 bytes entry is not supported.

If the size is 64 bytes, then files must be block aligned. If they are 128 bytes, then you can have data that says what the offset inside a block is.

Anyway, the full specification is here: http://microsea.googlecode.com/files/tfs_03.doc
Edit: Fixed a few things...lol
Please, comments? Suggestions? Criticisms?
this is my first serious attempt at a filesystem
-JL

I like it. I think I'll use it for my kernel's ramdisk. (now I just need to figure out how to load the image...)

piranha , if this is easy like you said, i declare you a genius, i dont know if i want to use it yet, but when i have the time and the confidence, i will look to you (or the google code link you put down).

good job!

This is impressive. You got
[*]long file names
[*]permissions
[*]time stamps

Really that's all the features I've been looking for, along with fairly easy to implement...

hmm... Is this filesystem simple enough that you can implement a bootloader in it without having to fix the bootloader with block constants or something of your second stage loader? that would be somethign I'd really like to know..

I don't really know much about bootloaders, as I decided not to write one myself. So I wouldn't know...

-JL

8 bits to describe rwxrwxrwx? (9 fields!)

Combuster: Good point.

I've updated/changed the index entry specs a bit to accommodate this, now the permissions field is 2 bytes long.
--> http://microsea.googlecode.com/files/tfs_03.doc

-JL

This is actually really nice...
It's like a simpler and better version of FAT12.

You need to work on the MFT to make performace better

Interesting, but I don't want to change the specs at this point...

-JL

How does fragmentation increase read speed?

Fragmentation increases read tima as the file system driver will have to jump around to various sector locations on the disk (not in a sequential order, hence 'fragmented') to read a single file, the time penalty incurred can sometimes be negligible for small files but for big files or an app reading hundreds/thousands of file in quick succession this time penalty can be very noticable.
The extra time to read a fragmented file is the time it takes for the disk drive to seek to the various sectors/segments of the fragmented file, where as, a non-fragmented file will be one sector after another so its the minimum possible sector seek time.

Kieran