> In the mean time, I may give a try with implementing Minix v2 filesystem.

I've been looking for even simpler file systems than FAT, too. And I've found 
minix as well. ;-) But, just as you said, minix v1 is too restricted for 
today's demands, and v2 is not so simple.

I've even been thinking about creating a new file system... I wouldn't be 
capable of "mounting" it, but I would write userspace programs for linux to 
create and modify such a file system.

Things I had in mind to make it as simple as possible...

- No directories
- Filenames do not contain letters, just numbers from 0..65535
- There is no FAT-like structure at a certain point on the disk, but metadata 
on where to find the next sector (and perhaps the previous) is stored inside 
the data sectors, so not more than one sector has ever to be held in RAM
- There could, however, be a bit-field with one bit per sector indicating if a 
certain sector is free or occupied. This field would require 1024 sectors (=512 
kByte) for a 2GB SD card

Some limitations are obvious: 
- 65535 files max.
- Seeking in a file is slow, as "skipped" sectors have to be read to get the 
metadata
- Calculating the size of a file is very slow, as the whole file has to be 
read. This is also necessary to append to a file

Benefits are:
- Directory is very small, only two bytes for the filename
- Linear reading is very fast, each read sector contains user data
- No immanent limit on file size
- With 4-byte sector numbers, volume sizes up to 1TB possible

But... I'm quite busy with other things... I have no idea if I will be starting 
to work on that this year ;-)

Greets,
Kiste

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/jallib?hl=en.

Reply via email to