CSCI 333

Storage Systems

Home | Schedule | Labs | Williams CS | Piazza

Lab 2: Hello, FUSE!

Objectives

This assignment serves several purposes. The main goal is to build comfort with FUSE so that we may implement a rudimentary FFS-like file system in upcoming weeks. Specifically, by the end of this lab you should:

• be able to install and run system software on a department "Panic" machine
• be able to implement core file system functionality in FUSE
• be able to mount and interact with a barebones FUSE file system
• be able to attach a debugger to your running FUSE file system
• collaborate using Git

Overview and Credit

In this assignment, you will be writing a very simple pseudo-filesystem that slightly extends the basic functionality of the "Hello world" file system example from the FUSE source code repository. This lab (and the subsequent FUSE FAT-fs labs) are modified from assignments created by Geoff Keunning at Harvey Mudd College. I have adapted the lab below, but you are encouraged to explore resources from his version if you are interested (you should not need to do so to complete this lab, but you may wish to look ahead). Note that you should never seek out or view source code or solutions to these labs. Any attempt to do so would be considered a violation of the honor code.

Getting Started

For this lab, we will use two starter files from FUSE version 2.9.5's examples/ directory (later FUSE versions broke backwards compatibility; API version 26 is the one installed on our Lab's Ubuntu machines), which I have included in your repositories: fusexmp.c and hello.c.

To quote the README from the FUSE repository:

"FUSE comes with several example file systems in the examples directory. For example, the fusexmp example mirrors the contents of the root directory under the mountpoint. Start from there and adapt the code!"

So let's do that. After cloning your team's private repository, start by copying fusexmp.c to my-hello.c, then use this "new" hello.c as a guide to and implement stubs for all the functions that aren't needed in your simple program. Through this process, you will familiarize yourself with much of FUSE, learn how to return errors, and develop a framework that will be useful when we begin our FUSE Simple FS implementation. Please explore other example file systems in that directory.

Your Task

In this lab, you will develop a filesystem with the following characteristics:

• There is a single file, with a name of your choice (I'll use cs333.txt as an example).
• ls and ls -l should work on the root directory, and return plausible values for ".", "..", and "cs333.txt". You must make sure that "cs333.txt" always has the correct length, even after modification.
• The access() system call should work and it should correctly indicate that"cs333.txt" can be both read and written by its owner.
• "cs333.txt" (or whatever you name your file) should initially contain a short string of your choosing (e.g, "What is my purpose? Why am I here?"). For cosmetic reasons, it should be terminated by a newline, but do not include a trailing null byte.
• When read, "cs333.txt" (or whatever you name your file) should return its contents (following the appropriate behavior of read).
• Writes to "cs333.txt" (or whatever you name your file) should overwrite the contents of the file, possibly extending the string if the data extends beyond the current file's size. However, you may choose a maximum file length (perhaps 80 bytes?) and reject any writes that attempt to grow the file beyond that size (and if you reject those writes, return an appropriate error of course).
• Note that implementing write correctly requires that you also implement truncate. The truncate system call can be used to shorten OR lengthen a file. If you extend the length of the file, make sure to zero-fill bytes beyond the previous file length so that you do not have uninitialized data in your file.
• Other operations are up to you. Anything unimplemented should return an error code. The error code ENOSYS is appropriate for unimplemented system calls. The complete list of error codes can be found in /usr/include/asm-generic/errno*.h; The most common error codes have values below ~50.

Development Environment

You can do your development on any machine that you choose. You and your team will be given your own department "panic" machine, and you will have sudo privileges: you will be able to install any system software that you need/want, and you can completely customize your environment. However, your final code will be tested on an Ubuntu 16.04 machine using FUSE version 2.9.4 (the default version in Ubuntu 16.04's repository).

Compiling

Compiling a FUSE program requires a slightly complicated command:

             $ gcc -g -Og my-hello.c -o my-hello `pkg-config fuse --cflags --libs`

A better approach, of course, is to use make. I have placed a minimal Makefile in your repository that will compile the single C file, my-hello.c, using the appropriate commands. I encourage you to further develop this Makefile to fit your needs.

FUSE

As linked from the readings, Professor Keunning maintains a Web page with reference FUSE materials.

Running & Testing

The above FUSE documentation page contains instructions on how to run and debug FUSE programs in general.

For this assignment, be sure to test not only that you can read your file, but that you can write to it and that you get back precisely what you wrote. An easy way to test your writing is to redirect program output to the file:

             $ echo "Here is some new text for my file." > testdir/cs333.txt

Evaluation

Your my-hello.c FUSE file system will be evaluated on correctness (it should implement the behavior as described above), code clarity, and error-handling. Please test and verify your implementation. You may wish to write your own tests; feel free to commit them alongside your code.

Submitting Your Work

When you have completed the lab, submit your code using the appropriate git commands, such as:

	  $ git status
	  $ git add ...
	  $ git commit -m "final submission"
	  $ git push

Verify that your changes appear on Github. Navigate in your web browser to your group's private repository on GitHub. It should be available at https://github.com/williams-cs/cs333lab01-{USERNAME1}-{USERNAME2} You should see all changes reflected in the various files that you submit. If not, go back and make sure you committed and pushed.

We will know that the files are yours because they are in your git repository. Do not include identifying information in the code that you submit. Our goal is to grade the programs anonymously to avoid any bias. However, in your README.md file, please cite any sources of inspiration or collaboration (e.g., conversations with classmates). We take the honor code very seriously, and so should you. Please include the statement "We are the sole authors of the work in this repository." inside your README.md file.

This contents of this lab borrow heavily from a homework written by Geoff Keunning as part of his CS137 course materials.