CSCI 333

Storage Systems

Home | Schedule | Labs | Williams CS | Piazza

Lab 2b: FUSE FAT, part II

Objectives

In lab 2b, you will (1) finish the prototype FAT filesystem you began in lab 2a, and (2) add enough functionality to your prototype filesystem that it can be used to store actual data in mutable files.

The Assignment

Your assignment is to finish the FAT-like filesystem that you began in lab 2a. Your finished filesystem should have the following features:

• The general structure of the filesystem is similar to the Microsoft FAT design (see lab 2a's description).
• In addition to all of the calls supported in lab 2a (getattr, access, readdir, and mkdir), you must support the following additional operations: close (i.e., release), create, fgetattr, mknod (only for plain files), open, read, readlink, rmdir, statfs, symlink, truncate, unlink, and write.
• You are not required to support chmod, chown, fsync, link, rename, or utimens. Note that many of these operations require additional filesystem design (e.g., chown requires that you track ownership).
• Your write operation must support full Unix semantics: it must be possible to extend a file by writing at the end, to rewrite arbitrary bytes in the middle of a file, and to extend a file by a large amount by seeking far past the end and writing a single byte.
• You are not required to support sparse files (a sparse file is a large file that does not explicitly represent all of the "holes"; instead it creates "0"s on demand).
• Directories should be variable-sized and should grow as files are created within them. However, it is not necessary to shrink directories when files are removed.
• The statfs operation should correctly report the amount of free space in the file system. In particular, if it says that n blocks are left, it should be possible to write n additional blocks of data to an existing file, and impossible to write n+1 blocks.
• Note that your path-evaluation code doesn't need to do anything special for symbolic links; FUSE will do that for you.

Testing your File System

Many of your features can be tested using standard Unix utilities (the dd utility is especially useful—see `man dd`). I strongly recommend that you write special test code or scripts. As soon as you add functionality, create a unit test. Then run all of your existing unit tests to verify your new "feature" didn't break anything! I recommend creating a separate folder of test scripts.

Here are some things that I expect to work, so you are encouraged to create at least tests for these features:

• Subdirectories (and sub-sub, and…)
• Files and directories with (modestly) long names (e.g., over 16 characters)
• Directories with many entries (enough that the directory requires more than one disk block)
• Symbolic links
• ls -la, including for symlinks and files of various sizes, and including . and ..
• Zero-length files
• Very large files
• Extending files (e.g., with `echo xxx >> foo`)
• Extending a file while overwriting a few bytes at the end
• Truncating files to zero length
• Truncating files to nonzero length
• Using truncate to extend files by adding zeros
• Changing a few bytes in the middle of a file (hint: invoking dd with the conv=notrunc switch is one way to do this)
• statfs (hint: the df command uses that call)

The above is not an exhaustive list. Try to think of what has been (deliberately) omitted.

Important Notes

Refer back to the important notes in lab 2a to make sure you don't do anything silly. In addition:

• Your implementation must be (reasonably) efficient. It should be possible to create a 1-MiB file in well under a second.
• You should not waste memory. It's OK to store the entire FAT in memory; that's what DOS did. But you may not store a copy of the entire disk in memory, nor may you at any time store an entire file or directory in memory. The sole exception is 1-block files, which of course may be assumed to fit…

Submission

Commit your code (it should be inside a single file named FAT.c) to your git repository. If you implement any additional features, describe them prominently in your README.md file so that you receive credit. So that I know that you have finished, please use the commit message "lab 2b submission" when you commit your final version. If you later realize that you were not done, you can continue to make additional commits, but it should be clear from the output of `git log` which version of your code is your submission.

This lab borrows heavily from an assignment created by Geoff Kuenning, with only slight modificatons.