Project 4: File Systems
In the previous two assignments, you made extensive use of a file system without
actually worrying about how it was implemented underneath. For this last
assignment, you will improve the implementation of the file system. You will be
working primarily in the
You may build project 4 on top of project 2 or project 3. In either case, all of
the functionality needed for project 2 must work in your filesys submission. If
you build on project 3, then all of the project 3 functionality must work also,
and you will need to edit
filesys/Make.vars to enable VM functionality. We
will deduct 10% credit if you disable the VM.
Note that the page cache (extra credit) requires the VM functionality.
Here are some files that are probably new to you. These are in the
except where indicated:
Simple utilities for the file system that are accessible from the kernel command line.
Top-level interface to the file system. See Using the File System, for an introduction.
Translates file names to inodes. The directory data structure is stored as a file.
Manages the data structure representing the layout of a files data on disk.
Manage the FAT filesystem.
Translates file reads and writes to disk sector reads and writes.
Page cache implementation that utilize vm functionalities. We strongly recommend you to use this template. But you might write down your own codes. Note that if you turn off the vm flag, you cannot use this template.
A bitmap data structure along with routines for reading and writing the bitmap to disk files.
Our file system has a Unix-like interface, so you may also wish to read the Unix
man pages for
creat, open, close, read, write, lseek, and
unlink. Our file
system has calls that are similar, but not identical, to these. The file system
translates these calls into disk operations.
All the basic functionality is there in the code above, so that the file system is usable from the start, as you've seen in the previous two projects. However, it has severe limitations which you will remove.
While most of your work will be in
filesys, you should be prepared for interactions
with all previous parts.
Testing File System Persistence
Until now, each test invoked Pintos just once. However, an important purpose of a file system is to ensure that data remains accessible from one boot to another. Thus, the tests that are part of the file system project invoke Pintos a second time. The second run combines all the files and directories in the file system into a single file, then copies that file out of the Pintos file system into the host (Unix) file system.
The grading scripts check the file systems correctness based on the contents of the file
copied out in the second run. This means that your project will not pass any of the extended
file system tests until the file system is implemented well enough to support
tar, the Pintos
user program that produces the file that is copied out. The
tar program is fairly demanding
(it requires both extensible file and subdirectory support), so this will take some work. Until
then, you can ignore errors from
make check regarding the extracted file system.
Incidentally, as you may have surmised, the file format used for copying out the file
system contents is the standard Unix "tar" format. You can use the Unix tar program to
examine them. The tar file for test t is named