CSCI 333

Storage Systems

Home | Schedule | Labs | Williams CS | Piazza

Final Project

Overview

The final project is your chance to use the knowledge, tools, and techniques that we have developed this semester to explore a topic that interests you. Your final project should be the size and scope of a two-week lab. However you have the opportunity to define the project parameters, provided they fall within the overall project guidelines (detailed below). I have also provided suggestions for projects that you may use or adapt to fit your interests/goals.

Timelines

The remaining "lab work" will be dedicated to a final project, and the instructor is there to assist with all aspects of the process.

Proposal

• You must propose a project by Friday, April 26 at 5pm. Proposals should be submitted in a README.md document. That README.md file will be added to the root of your group's github repository. Here is an example of a README.md for a project that extends Lab 2 by adding encryption.
• Your proposal must include meeting with Bill in person (possibly a scheduled meeting, but preferably during office hours or at the end of class).
• Your proposal should be detailed. It should include an outline of your ideas and plans for:
  • Implementation:
    • the external libraries/software projects you plan to use
    • the final project "deliverables" (code, graphs, documentation)
  • Evaluation:
    • how you will measure/evaluate the thing that you built
    • how you will compare it to the current state-of-the art (if applicable)
    In other words, before you begin any work, you should define what "success" means in the context of your proposed project. You will not be graded on whether or not you achieve that outcome; so-called "negative results" are still valid science. But you must be able to articulate what you are working towards, and when done, what you've learned along the way.
• I am happy to brainstorm with you on your proposal!

Final Project

• The project will be due on Sunday, May 12 at 11pm.
• In addition to your code, a short write-up must be summitted as a PDF in 2-column conference-style formatting. It should be no more than 5 pages, including references. Communication is an important part of research, and it will give you a chance to document and celebrate your hard work.

Guidelines

Final projects may be:

• Completed in groups of 2-3 students
• The project scope should scale with the size of the group (I expect a team of 3 students to complete more work than 2 students)
• By default, you will be partnered with your current FUSE teammates. However, you may swap, merge, split, or dissolve those groups if desired. Your group's composition is up to you.
• You may make use of open-source code/projects if they enable you to pursue a topic in greater detail or depth.
• You may define your own project, or you may choose/modify a project idea from the examples below.
• Measuring and/or evaluating an existing system is itself a complex and worthwhile task (a successful workshop papers formula is to identify a problem and quantify the opportunity).

In addition to submitting your code and paper in a git repository, you must provide (brief) high-level documentation of your project in the README.md file. Project documentation must include:

• Your project proposal.
• A (brief) overview of why your project is interesting (technically and non-technically).
• Clearly written instructions that explain how to run your code, including how to install requisite libraries
• Conclusions that you have drawn at the end of your project, such as:
  • What were the challenges?
  • What questions still remain?
  • Given more time, what would be the next steps?
  • Would you do anything differently if you could start over?

There is no length requirement for your README.md. However, your README.md document and you conference-style writeup are the primary ways that we will interact with your project. Use them to tell your story! There is more to a project than just the numbers. I want to reward your effort, but in order to do so, I need you to tell me what you did.

Sample Project Ideas

This is a non-exhaustive list of project ideas. Some of them have been inspired by topics in this course, and some of them have been projects from computer science courses elsewhere. I suggest that you use them for inspiration, even if you decide to design your own project: techniques or suggestions might be relevant.

• Hardware measurment and benchmark design from an OS course at UNC
• Recreate the evaluation of a published research paper, and either confirm or dispute their results. Good candidates for this type of project are papers that have published their benchmarks and have provided clear discriptions of their methodology. You may wish consider some of the papers we have read in this course, such as:
  • Skylight-A Window on Shingled Disk Operation
  • File Systems Fated for Senescence? Nonsense, Says Science!
• Extend your FUSE file system in one or more interesting ways, such as:
  • implement a file system consistency checker
  • add SMR-support using libzbc
  • Extend it to be compatible with a real MS FAT file system image.
  • Add encryption and/or compresssion
  • Add intelligent caching
• Implement a new FUSE file system that does something interesting or fun.
  • Musical FUSE: writes to files proceed as normal, but reads use an external python library to "play" the contentents of the files. I will convert each file byte to a musical note, and play the corresponding tone. Repeated bytes will increase the duration of the note. The be a series of folders named by the speed of playback. I promise not to use this without headphones.
  • I will implement a pseudo filesystem for printing PDF documents. I will have two directories: single-sided and double-sided. There will be a single psuedo-file called "print", and when I write a file name to "print", the computer prints the contents with the appripriate sided-ness to the default printer (the printer is specified as a parameter during mount).
  • Operate as a pass-through file system, but issue git commits/pushes/pulls to keep your contents synced with a remote repository. This could be an interesting way to collaborate on a project. A challenge here would be handling merge conflicts, but this project seems both straightforward and fun!
  • rsync with a server for disconnected work on your files
  • Implement file-level compression on a "pass-through" style FS (i.e., you read and write using an existing file system, but you compress the file contents)
• Implement hardware conditioning scripts, and quantify the performance differences between fresh and aged devices. Here is a link to the SNIA document with details.
• Integrate SSD streams into an existing data structure or application.
• Collect summary statistics about modern storage systems. Things like compressibility, directory structure, file sizes, deduplication rations, etc. are interesting to practitioners.
• Design a CS136 lab on Bloom filters
• Download the code for a filter implementation (Bloom or quotient filter), and experimentally verify that the parameter settings produce the desired false positive rate.

Williams College :: CSCI 333 :: Spring 2019