Thread: Simple File System in C

  1. #1
    Registered User
    Join Date
    Oct 2009
    Posts
    5

    Question 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;
    };
    Any ideas if/how the above is going to work?
    Last edited by tsiknas; 12-20-2009 at 04:57 AM.

  2. #2
    Registered User
    Join Date
    Jan 2009
    Posts
    77
    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.

  3. #3
    Registered User
    Join Date
    Jul 2007
    Posts
    131
    Quote Originally Posted by quantt View Post
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Newbie homework help
    By fossage in forum C Programming
    Replies: 3
    Last Post: 04-30-2009, 04:27 PM
  2. File transfer- the file sometimes not full transferred
    By shu_fei86 in forum C# Programming
    Replies: 13
    Last Post: 03-13-2009, 12:44 PM
  3. Replies: 2
    Last Post: 03-05-2009, 10:25 AM
  4. opening empty file causes access violation
    By trevordunstan in forum C Programming
    Replies: 10
    Last Post: 10-21-2008, 11:19 PM
  5. Replies: 3
    Last Post: 03-04-2005, 02:46 PM