Simple File System in C

This is a discussion on Simple File System in C within the Linux Programming forums, part of the Platform Specific Boards category; As a part of an exersice we are called to write a simple file system in C.
It will be ...

Simple File System in C

As a part of an exersice we are called to write a simple file system in C.
It will be a flat file system without directory hierarchy and without access control list.
These things must have:
Superblock (with information about the filesystem and the sizes of the below items)
Block bitmap (this can be done using ints, i dont know how to manipulate single bits)
i-node bitmap (same here)
Directory table (with high level filenames and the i-node indexes which have the info about the files)
i-nodes (This is the part were I'm stuck.)

I understand that an i-node indexes a group of blocks.
We cant store something smaller than the size of an i-node
(if its smaller the rest stays unoccupied if ts bigger we use more i-nodes)

- How many blocks per i-node do we assign?
(is it static or it depents from filesystem specs (num of blocks and block size)?)

- How do we point to a block of the disk in C?
(can we use pointers?)

I came up with these structures:

Code:

#define uint unsigned int
enum bool {false=0, true=1};
/* Block service structures */
struct superblock {
char fs_name[15];
uint sb_count; //number of blocks superblock occupies
uint block_size;
uint block_count; //number of blocks file system has
uint bbitmap_count; //number of blocks block bitmap occupies
uint free_blocks; //how many blocks are free
uint fs_rsv_blocks; //how many blocks are reserved from file system structs
uint inode_size; //how many block an inode indexes
uint inode_count; //total blocks occupied by inodes
uint ibitmap_count; //how many blocks occupied by inode bitmap
uint fs_rsv_inodes; //how many inodes reserved from file system structures
//i think its wrong the above but i grouped in inodes all the blocks of the disk so in some of
//them will hold filesystem's structures (will not be used at the end)
uint dir_table_count; //how many blocks the directory table occupies
};
//an array of them will be created depended on how many blocks the filesystem will be
struct block_bitmap {
enum bool block_bitmap;
};
/* File service structures */
//an array of them will be created depended on how many blocks the filesystem will be
struct inode_bitmap {
enum bool inode_bitmap;
};
//here i need help, an unsinged integer to point to the first block of the group (inode size will used to know how many blocks after it we have)
struct inode {
uint block;
};
//structure to hold a single file, file size is used to know, how many inodes we have to search
struct index {
uint file_size;
struct inode inode;
struct inode *indirect;
};
/* Directory service structures */
//a linked list will used to hold the filenames
struct dir_table {
char filename[16];
struct index index;
struct dir_table *next;
};

hm, looks interesting things. Add in your filesystem wider stat() information, e.g. file type mp3,mp4,gif,jpeg,html, and so on it would be very useful.

stat(2) fills struct stat, which is defined by standard, so you can't just add more information. In addition to that, file system driver would become very bloated if it could check file's type. For example on my system /usr/share/misc/magic has information about over 9000 different types of files. I think it would be completely unnecessary to do file type recognition in kernel.