minixfs

Minix v2 filesystem implementation

Author Sebastien Lelong, Copyright © 2011, all rights reserved.
Adapted-by
Compiler 2.4o

Description

Minix v2 implementation
Partitions aren't supported, so you have to create a filesystem on the whole
available memory. Typically, instead of "mkfs.minix -v /dev/sdX1", you'll
have to "mkfs.minix -v /dev/sdX" (and remove sdX1 partition with fdisk)
Some useful commands:
 - fsck.minix -f -v -s /dev/sdX
      will print Super-Block and some other information about files, dirs, state
 - hexdump -C /dev/sdX
      will dump Minix FS content (only changing lines)
 - hexdump -v -C /dev/sdX
      will do the same, but dump all lines, even if identical
.
In order to test your setup, you can untar minix_data.tar.bz2 available at:
... 
This archive contains directories and files of different size, used to test
data zone and helping to understand how Minix filesystem is designed.
   1. prepare your device, no partition (replace /dev/sdX with appropriate device):
         mkfs.minix -v /dev/sdX
         mount /dev/sdX /mnt/tmp
   2. untar test data:
         cd /mnt/tmp && tar xjfv path/to/minix_data.tar.bz2
         cd && umount /mnt/tmp
   3. check content:
         fsck.minix -f -v -s /dev/sdX
      should report something like (1GB SD-card used here):
.
Forcing filesystem check on /dev/sdX.
65535 inodes
992000 blocks
Firstdatazone=4227 (4227)
Zonesize=1024
Maxsize=2147483647
Filesystem state=1
namelen=30
.
    20 inodes used (0%)
 70858 zones used (7%)
.
    16 regu
    16 regular files
     2 directories
     0 character device files
     0 block device files
     1 links
     2 symbolic links
     ------
     21 files
.
Vocabulary: these are the terms I'm using in this code, may be wrong...
   * storage:  this is the underlying storage layer. Link between MinixFS and storage is done
               by creating aliases to some spefici proc/funcs. Typically, storage is sd_card.jal
               library. It could also be hard-disk too.
   * sector:   this is a unit in underlying storage (eg. for SD cards, 512 bytes)
   * block:    this is a unit in minixfs (typically 1024 bytes, that is, 2 * sector's size with SD cards)
   * zone:     same as a block in case of Minix v2
   * inode:    well, that's an inode, a kind of meta description of a file
   * file descriptor: a structure composed with an inode and several information to track how file was
               opened and where we are within a file (well, again, that's a file descriptor)


Notes

   * I developped this lib and tested it with sd_card storage. It should be possible to use other
   * storages though not tested nor even tried.
   * to developpers: this piece of code is tricky... If you plan to modify this lib, take huge care
                     at variables initialization, there are special values I used, mostly to rollover
                     to 0 when first accessed. It could have been simpler but would have used more 
                     variables and thus more resources. There are many counters which, when reaching 
                     a specific value, trigger actions (like flushing data, going to next zone, allocate
                     a new zone, etc...). Just don't assume it'll work just because you added a small
                     little line, because everything is quite tied together and you could be victim
                     of an (un)expected butterfly effect :) I myself broke features many times with 
                     supposedly minor changes, hurting my brain a lot. Being polite...


Dependencies


Summary

Global variables/contants

Procedures

Functions


API details

Global variables/contants

Procedures

Functions

  • minix_zone_alloc() return dword

    Walk accross zone bitmap, searching for a free zone number (identified by 0s)
    and return available zone number. 
    /!\ zone bitmap and file's content obviously aren't located the same. This means when 
    allocating, we're moving in a different place (zone bitmap) than we previously were
    while writing into the file. It's the caller's responsability to move the correct location
    once allocation is done. Yes, that's right: it's dirty, as zone_alloc() won't let the system
    in its previous state. ("why ?" you may ask... because it's simpler like that, and anyway,
    this procedure is somewhat internal, so it shouldn't be a problem in the end).
    

  • minix_find_in_cwd(byte in filename[MINIX_MAX_FILENANE_LEN]) return word

    return inode number found for given filename
    can be a file or a dir name) in current directory
    

  • minix_last_error'get() return byte

    No documentation found

  • minix_read() return byte

    Read bytes from file descriptor.
    Walk over memory zones given, returning content
    byte by byte. firt walk over direct zones, then 
    swith indirect then double indirect zones. Keep
    track of progress within inode
    

  • minix_next_entry'get() return minix_dir_entry

    list current working directory (cwd), returning a 
    directory entry each time it's called, until no more
    entry found.
    

  • minix_storage_read_byte() return byte

    "Raw" read one byte from underlying storage.
    


Related samples

Here are the list of samples which use this library:

18f27j5318f27j53_sd_card_minix_demo.jal
18f27j5318f27j53_sd_card_minix_readi.jal
18f27j5318f27j53_sd_card_minix_read.jal