Hi guys, Some progress around Minix filesystem. I think I'm done implementing most important part about *reading* data, including direct, indirect and double indirect data zone. This brings file size up to 64MB, as Minix v2 specifications. Following Minix v3 specs (and allowing up to 2GB per file) should be too hard to add.
I added a testing dataset in order to check how zones are "walked", using direct zones up to 7K, then using indirect zones up to 263K, then using double indirect zones. Symlinks aren't supported (yet ?). While reading content, there's a kind of file descriptor logic: inode is loaded, it keeps track about several parameters like where it currently is within data zones, etc... It must be closed in order to open another, mostly to release underlying storage (ie. sd_stop_read()), and eventually to flush inode changes back to disk. For now, only one file descriptor can be used (global var minix_curinode). I tried to implement a real file descriptor table, but this really consumes a lot of resources, and I'm not sure about how useful it is. It's particularly hard to implement this with efficiency without pointers. I extensively use "record", so I can't put a sample in jallib repos since it requires jalv24o and repos is still using 2.4n. But there's one sample in jaluino repository, briefly showing how to deal with Minix API. It implements a REPL, display root directory content, user can select which file (inode number) to display. API goes like this: -- mount minix_init() -- open root directory minix_open(directory_inode_number) -- list directory's content var minix_dir_entry entry entry = minix_next_entry while entry.inode_num != 0 loop -- do something with directory entry end loop minix_close() -- implement "cat" command minix_open(inode_number) for minix_curinode.filesize loop serial_hw_data = minix_read() end loop minix_close() -- release storage Now the big part: write operations... Suggestions & comments welcome. Cheers, Seb 2011/4/20 Oliver Seitz <[email protected]> > > > 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.
