Link Search Menu Expand Document

Due by 11:59 PM on Sunday, Nov 22

Changelog

  • November 21, 2020: Part II release
  • November 21, 2020: Add clarifications about layout
  • November 08, 2020: Initial version

Introduction

In this project, you will take a deeper look at how filesystems are designed and implemented in modern computer systems. This project will focus on the creation of a filesystem driver to add support to Linux for reading and writing to a filesystem within a disk image file.

This project will involve creating a new filesystem driver for the filesystem described below, called the Multimedia Embedded Memory Encapsulation Filesystem. This new filesystem driver will be implemented using the FUSE library, which allows the creation of filesystem drivers entirely in user-space. We have provided you with code to create and format an image for this filesystem that you are welcome to use to help you design your driver. There is a possibility for extra credit on this assignment if an in-kernel filesystem driver (as a loadable kernel module) is developed in addition to the FUSE-based filesystem module.

Before you begin on the project, you will have to create your GitHub repository using the appropriate link posted on Piazza for your section. Unlike projects 2 and 3, this project will not require you to make any changes directly in the Linux kernel — the filesystem driver you develop will be done as a user-space program using the FUSE library. You may develop your assignment on either the default installed Debian kernel or the 5.5.0 kernel that we have been using for previous projects (there is no difference in developing FUSE filesystems on either).

However, if you attempt the extra credit portion that requires developing an in-kernel filesystem module, you will be required to base that code on a clean 5.5.0 kernel (without any modifications from previous projects).

You can find the source code for the formatting tool for this filesystem here and a Makefile to build it with is here.


Useful resources

Below is a list of references that you may find useful in your quest to complete this project:


Incremental Development

One of the nice things about using GitHub for submitting assignments is that it lends itself nicely to an incremental development process. As they say, Rome wasn’t built in a day — nor is most software. Part of our goal in using GitHub for assignment submission is to give all of the students in the class experience with using a source control system for incremental development.

You are required in this project to plan out an incremental development process for yourself — one that works for you. There is no one-size-fits-all approach here. One suggested option is to break the assignment down into steps and implement things as you go.

You should not attempt to complete this entire project in one sitting. Also, we don’t want you all waiting until the last minute to even start on the assignment. Students doing either of these on assignments in this class tend to get poor grades on the assignments. To this end, we are requiring you to make at least six non-trivial commits to your GitHub repository for the assignment. These six commits must be made on different dates and at least two must be committed and pushed to your repository by the due date for Part I of this project (Sunday, November 22nd at 11:59 PM EST). You may make more than six commits during the timeline of the project — six is simply a minimum number required for full credit.

A non-trivial commit is defined for this assignment as one that meets all of these requirements:

  • Does not contain only documentation (i.e, just committing a README file does not count).
  • Does not contain only Makefile modifications or creation.
  • Modifies/creates at least 10 lines of code in a combination of existing or newly created .c or .h files. That is to say, creating a new file with 10 lines of code counts, but creating a new file with a 10 line comment does not.
  • Code modifications/creation must be relevant to the project. Creating a bunch of useless files/functions that are unrelated or otherwise superfluous to the assignment does not count. It is ok to reorganize your code after you have started and remove pieces of code, of course, but if you are obviously only adding code to the repository early on that you completely delete later (or that has nothing to do with the assignment), then that commit will not count toward the requirements herein.

Failure to adhere to these requirements will result in a significant deduction in your score for the assignment. This deduction will be applied after the rest of your score is calculated, much like a deduction for turning in the assignment with a late penalty.