Sample Input file

TFS: A Trivial Unix-like File System

• The file system resides on a disk that is 128KB in size.
• There is only one root directory. No subdirectories are allowed.
• The file system supports a maximum of 16 files.
• The maximum size of a file is 8 blocks; each block is 1KB in size.
• Each file has a unique name, the file name can be no longer than 8 characters.

The layout of your 128 KB disk is as follows

• The first 1KB block is called the super block. It stores the free block list and index nodes (inode) for each file.
• The remaining 127 1KB blocks store data blocks of the files on your file system.
• The exact structure of the super block is as follows.
  • The first 128 bytes stores the free block list. Each entry in this list indicates whether the corresponding block is free or in use (if the i-th byte is 0, it indicates that the block is free, else it is in use). Intially all blocks except the super block are free.
  • Immediately following the free block list are the 16 index nodes, one for each file that is allowed in the file system. Initially, all inode are free. Each inode stores the following information:

    char name[8]; //file name
    int size;     // file size (in number of blocks)
    int blockPointers[8]; // direct block pointers
    int used;             // 0 => inode is free; 1 => in use
    

    Note that each inode is 48 bytes in size, since a char has size 1 and an int has size 4. Together, all 16 inodes take up 768 bytes. Combining this with the free block list gives us a total size of 896 bytes for the super block. The super block may not fill the 1 KB, but start writing file blocks after 1KB into the disk.

You need to implement the following operations for your file system.

• create(char name[8], int size): create a new file with this name and with these many blocks. (For simplicity, we shall assume that the file size is specified at file creation time and the file does not grow or shrink from this point on)

• delete(char name[8]): delete the file with this name

• read(char name[8], int blockNum, char buf[1024]): read the specified block from this file into the specified buffer; blockNum can range from 0 to 7.

• write(char name[8], int blockNum, char buf[1024]): write the data in the buffer to the specified block in this file.

• ls(void): list the names of all files in the file system and their sizes.

Getting Started

• We will use a 128KB file to act as the "disk" for your file system. We have provided a program to create this file for you and format it. Run this program by typing the command
  

   create_fs disk0

  This will create a file with the name

  disk0

  in your current directory. The program also "formats" your file system---this is done by initializing all blocks in the super block to be free and marking all 16 inodes to be free. The file create_fs.c in the starter code allows you to create an empty file system.

  The starter code on moodle also includes a file FileSystem.cpp that includes the template code for your file system. We have provided copious comments for each method so that you know how to implement each function.

• Remember that your file system must be persistent. If you shutdown your program and then restart it at a later time, all files on your file system must be intact.

• Input file

  Your program should take input from a input file and perform actions specified in the file, while printing out the result of each action. The format of the input file is as follows.

  diskName  // name of the file that emulates the disk
  C fileName Size //create a file of this size
  D fileNAme     // delete this file
  L              // list all files on disk and their sizes
  R fileName blockNum // read this block from this file
  W fileName blockNum // write to this block in the file (use a dummy
  1KB buffer)
  
  

  An sample input file looks like this:

  disk0
  C file1 3
  W file1 0
  W file1 1
  C lab.java 7
  L
  C file2 4
  R file1 1
  D lab.java
  L
  

  A sample input file is also provided in the starter code. Be sure to print out what your program does after reading each line from this file. It'd also be helpful if you printed out the disk addresses of any block that you allocate, deallocate, read or write.

  Like in the previous assignment, the test directory contains some simple tests for your filesystem implementation. You should write your own tests for each function you implement: read, write, create, ls, delete. The tests can use the GTest framework but they don't need to. You can use specific input files to test your code (for example, trying to create an existing file should give you an error, or trying to delete a non-existent file should be an error, or listing files after deleting a file should no longer list the file etc). Your readme file should contain details of how you tested each function of the file system using valid and invalid inputs. You should also provide a brief description of how you debugged your code - either with a debugger of through other means.

  ---

  Design Document and Observations

  Once you have written your version of the file system code, write a design document that documents your design choices. The design doc should be written in plain text in a file called README.txt.

  The README file should also document observations from running your code with various inputs and your experience with testing / debugging and the test case you wrote.

  ---

  Starter Code

  The starter code will be made available on moodle.

  ---

  How to Turn in Lab 3

  1. We will use the gradescope autograder system to submit and grade your assignment.

     It is important that you keep the directory structure the same as what we have given to you in the starter code. You may not be able to receive a grade otherwise.

     To submit your code to gradescope, you need to create a zip file and upload it through your gradescope account. Your should zip your src and test folders directly into a zip file (do not zip the parent directory). You can use the following command: zip -r mycode.zip src test to create the zip file, or use any GUI based method or zip program to create the zip file. For example, on a Mac, select the src and test directory using the command key and then right click to select "Compress two items".

     Once you upload to gradescope, it will run some tests and let you know how many tests passed or if your code failed to complile or failed to terminate. While we will not reveal the test cases, we will give you brief indication of the type of tests that failed on your code to help you understand what may be going wrong. You can submit as many times as you wish to gradescope until the deadline or until your code passes all tests.

  2. This lab may be done individually or in groups of two. Groups with more than two students are not allowed. Your README file should clearly indicate at the beginning whether your project is being turned in as individual work or as group work. If it is group work, clearly mention the names of both group members.
  3. The README file should also contain an outline of what you did. It should also explain and document your design choices. Keep it short and to the point. If your implementation does not work, you should document the problems in the README, preferably with your explanation of why it does not work and how you would solve it if you had more time.
  4. Of course, you should also comment your code.
  5. Note: We will strictly enforce policies on cheating. Remember that we routinely run similarity checking programs on your solutions to detect cheating. Please make sure you turn in your own work.

     You should be very careful about using code snippets you find on the Internet. In general your code should be your own. It is OK to read tutorials on the web and use these concepts in your assignment. Blind use of code from web is strictly disallowed. Feel free to check with us if you have questions on this policy. And be sure to document any Internet sources/ tutorials you have used to complete the assignment in your README file.

  6. Late Policy: Please refer to the course syllabus for late policy on labs assignments. This late policy will be strictly enforced. Please start early so that you can submit the assignment on time.

  Lab 3 Grading Scheme

  (max 100) Total Grade

  • (60) autograder tests on Gradescope
  • (15) Correctness of code through manual grading
  • (10) design document in README.txt
  • (5) code comments
  • (10) test cases

  ---