Project 4 - File Systems

Administrivia: This project should be done in groups of 3. We'll assume the same groups as the last project. If you feel the need to change groups, please let Tom know as soon as possible.
Out: Wednesday, February 25
Due: Wednesday, March 10

Assignment Goals


The starting point for this assignment is a simplified file system, cse451fs, the design of which imposes strict limits on both the number of files that can be stored and the maximum size of any one file. In particular, no matter how big a disk you might have, this file system can hold only about 8,000 distinct files, no file can be larger than 13KB, and file names cannot be longer than 30 characters. These restrictions result from the choice of on-disk data structures used to find files and the data blocks of a given file, that is, the superblock and inode representations.

Here are the major steps involved in this assignment:

  1. Make sure that you, individually, understand the mechanical aspects of the "development environment" you'll be working in. These include how to build the file system code, how to configure the raw disk device provided by VMware to host your file system, and how to run and test your file system. A description of these mechanical aspects is here.

  2. Of the three limitations cited above you will need to improve the following two:

    Design how you want to implement these file system modifications on disk: how you will represent your directories on disk, how file data is indexed, etc. There can still be a limit on any of these properties, but your improvement needs to be more than simply altering a program constant.

    If you still have time left over, you may do additional improvements for up to 10 points of extra credit. Just for reference, 10 points of extra credit will be roughly equivalent to one homework assignment. Some ideas:

  3. Alter the skeleton code (/cse451/projects/cse451fs.tar.gz) to implement your file system. There are two major components to this. One is that the user level program mkfs.cse451fs must be changed to initialize the raw disk device with a valid, empty file system using your new on-disk data structures. The other is to change the file system source (fsSource/) itself.


Hints/Starting Points

The Writeup

The writeup should be hardcopy, handed in at the beginning of lecture on the due date. This writeup is less free form than previous ones have been. In particular, please adress the following:
  1. Describe the design for your file system modifications. This might include a discussion of other approaches you considered but rejected.
  2. What concurrency-related issues does a file system have to deal with? You probably didn't deal with any of it directly when implementing your extentions, but what did you notice when looking at the rest of the code?
  3. What methodology did you follow in order to test your file system (for functionality)?
  4. Does your implementation work? If not, what parts work and what parts don't? How would you fix it if you had more time?
  5. What do you like best about your design? What do you like least about it? How would you improve your design?
  6. If you did any extra credit, describe what you did. Make sure to describe how you implemented it, and how it solves the problem you set out to fix.

As a basic guideline, 4 pages would be a good total length for your report. As usual, the writeup is the bulk of the grade, so don't skimp on it.

Electronic Turnin

You will be turning in 3 files: a tar.gz file containing all of your modified sources, your compiled mkfs.cse451fs and cse451fs.o files.

To create the source archive file, do the same as you've done in the past, just do a make dist in the top level directory.

Use the turnin(1L) program under project name project4 before class on the day it is due. Note: turnin will not work on coredump/spinlock, so you'll need to use attu.