Sunday, December 7, 10pm. Pre-submission due on Saturday, November 29, 10pm, but we recommend getting the part done well before that. See Deliverables.
Note that, due to the logistics of grading and the final grades deadline, we can only offer you to use 2 of your slip days for this project.
See Project 2 on Canvas for the Github link.
You can work on this assignment in a pair, or alone.
Submit the contents of your repository via Gradescope. See Deliverables below for what to submit. If you are working with a partner, do not forget to include their name with the submission.
Note: There will be no autograder for this assignment as we have no way of running a custom filesystem on Gradescope. We have provided tests.
Note: Clone and start studying the starter code as soon as possible. This assignment will likely require more programming effort than previous assignments.
In this assignment you will build a FUSE filesystem driver that will let you mount a 1MB disk image (data file) as a filesystem.
We also provide an ungraded exercise set that will lead you through installing FUSE and familiarizing yourself with parts of the starter code.
For this assignment you will need to have the FUSE framework installed in your Linux. For WSL2 or Codespaces, you’ll need to install the following packages:
libfuse-devpkg-configRunning
$ sudo apt-get update
followed by
$ sudo apt-get install libfuse-dev pkg-config
should do the trick.
Note, that while there is an implementation of FUSE for macOS, we do not recommend using it and do not support it.
After completing this step, go to Pre-submission and submit the repository as requested by Saturday, November 29, 10pm.
You should extend the provided starter code so that it lets you do the following:
You will need to extend the functionality in nufs.c,
which only provides a simulated filesystem to begin with.1
This will require that you come up with a structure for how the file
system will store data in it’s 1MB “disk”. You should be able to support
128 files within that 1MB. See these File
system slides and OSTEP,
Chapter 40 for a conceptual overview of a file system
implementation. While you can choose to structure the file system
however you like, we generally assume a design close to the one
presented in OSTEP and in class.
We have provided some helper code in the helpers/
directory. You can use it if you want, but you don’t have to. However,
blocks.{c,h} and bitmap.{c,h} might save you
some time as these implement block manipulation over a binary disk
image. Feel free to extend the functionality if needed.
Some additional header files that might be useful are provided in the
hints directory. These are just some data definitions and
function prototypes to serve as an inspiration for abstraction layers.
They are provided “as-is”, meaning you’ll need to make sense of them.
Reading up on file system implementation in the OSTEP book might help.
If they don’t seem helpful, you are free to implement your own
abstractions.
In this step, implement support for arbitrarily nested directories. The filesystem should support the following operations on directories:
mkdir)rename)readdir)rmdir)Extend the filesystem to support files larger than 4K. The files must fit into the free blocks on disk. This must include proper allocation and deallocation as the file grows or shrinks. The file system needs to be able to handle the following example situations without re-compiling or regenerating a new image:2
Please read the instructions carefully and ask questions. If you do not submit to the correct assignment on Gradescope, we cannot guarantee that we will grade your assignment before the end of semester.
After doing Step 1, that is, after cloning the repository and installing FUSE,
Execute the following commands:
$ make nufs
$ ./nufs --version data.nufs > fuse_versionCommit the file fuse_version to your repo
Submit your repository to Gradescope under Project 2: Pre-submission by Saturday, November 29, 10pm. No late submissions are allowed for this step.
Modify the starter code to implement the requested functionality (steps 2, 3.
Commit the code to your repository. Do not include any executables,
.o files, or other binary, temporary, or hidden files
(unless they were part of the starter code). Do not include any disk
images.
Once you are done, remember to submit your solution to Gradescope and do not forget to include your partner. Submit under Project 2: Main Submission
For extra credit, submit code implementing the complete file system, including the large file extension to Project 2: Extra Credit on Gradescope. Remember to add your partner to the submission.
The provided Makefile should simplify your development cycle. It provides the following targets:
make nufs - compile the nufs binary.
This binary can be run manually as follows:
$ ./nufs [FUSE_OPTIONS] <mount_point> <disk_image>make mount - mount a filesystem (using
data.nufs as the image) under mnt/ in the
current directory
make unmount - unmount the filesystem
make test - run some tests on your implementation.3 This is a subset of tests we will
run on your submission. It should give you an idea whether you are on
the right path. However, do run through scenarios with your file system,
either manually or by writing scripts that exercise some
functionality.
make gdb - same as make mount, but run
the filesystem in GDB for debugging
make clean - remove executables and object files, as
well as test logs and the data.nufs.
The grade is broken down into three categories:
A fully working implementation of big files, correctly submitted, will earn 2% of the final course grade.
/usr/include/fuse/fuse.h (available online
athello.c.make mount) in one terminal
window and try file system operations on the mounted filesystem in
another separate terminal window.-ENOENT). Some things don’t
work if you don’t return the right error codes.getattr early and make sure it’s
correct. Nothing works without getattr. The modes for the
root directory and hello.txt in the starter code are good
default values for directories and files respectively.dirname and basename exist,
but may mutate their argument.That is, a filesystem which responds to some file I/O system calls consistently, but does not actually store any data.↩︎
I.e., we should be able to create/write/read 128 files in the root directory and delete them, then do the same with 5 100K files, then do the same with a 800K file, and repeat the process an arbitrary number of times.↩︎
These tests are written in Perl. You will need to have a
Perl interpreter installed. It should be available (even pre-installed)
on any Linux distribution. If you get an error about missing Perl
modules try using the command cpan install Test::Simple.↩︎