UFS: Introduction

For this assignment, you are expected to implement a unix-style mini file system running in OS user land. You should implement the program to run in Linux at least.

The whole structure of the file system will exist within the single file. You'll be storing and removing other files within this file system, which is just a file itself.

The structure of this file is as followings:

SuperBlock

Bit Map

Root Directory

Inodes

DATA Blocks

The SuperBlock is the first block in the disk that contains global information about the file system. You can store in the superblock things like starting location of the first block of the bit map, the root directory, the total number of free blocks, the overall size of the file system and any other thing you consider useful for making the file system persistent.

The root directory maintains the mapping between file names and inode numbers (or pointers). And the inodes has information about the data blocks in the file.

For simplicity, you can assume:

1. Your file system need not support multi-level directories. There is only a single-level directory in your file system. And this directory contains at most 100 files.
2. Each file contains at most 100 data blocks. Thus, The size of each file is less than (block size) * 100. You can define the size of data blocks yourself.
3. Inodes in your system contain only (at most 100) direct pointers that points to data blocks. No indirect pointers are required.

Program usage

Note: The number and size of files is also limited by the number of inodes and the number of free blocks.

• ./userfs --format disk_size --disk file_nam

  Should create a virtual disk with the file name and size specified as arguments.

• ./userfs --disk file_name directory

  Should mount the file system with the name of virtual disk specified as argument and attempt to recover the file system if there is any inconsistency.

• ./userfs --disk file_name -d directory

  Same as above, but in debug mode

UFS: Objectives

• Be familiar with file system APIs
• Able to implement file system APIs
• Able to interact between underlying media and fs APIs
• Understanding some fundamental inconsistency problems introduced in file system

UFS: Skeleton Code & FS APIs

Download the skeleton code userfs.zip and work upon it to export the following functions. First, you should create a file under the current directory. This file simulates the virtual disk based on which you will build your file system.

• static int fs_getattr(const char *path, struct stat *stbuf):
  Retreives information about the file at path. Returns 0 on success, or -ENOENT on failure
• static int fs_readdir(const char *path, void *buf, fuse_fill_dir_t filler, off_t offset, struct fuse_file_info *fi):
  Retreives list of files in the root directory, puts the result into buf using the filler function
• static int fs_create(const char *path, struct fuse_file_info *fi):
  Create an empty file named path
• static int fs_open(const char *path, struct fuse_file_info *fi):
  Opens a file
• static int fs_read(const char *path, char *buf, size_t size, off_t offset, struct fuse_file_info *fi):
  Reads the contents of the file at path into buf
• static int fs_write(const char * path, const char * buf, size_t buff_size, off_t offset, struct fuse_file_info * fi):
  Writes the contents of buf into the file at path
• static int fs_truncate(const char * path, off_t offset):
  Trim the file at path to the specified offset
• int fs_unlink(const char * path):
  Removes the file at path
• int fs_rename(const char * oldpath, const char * newpath):
  Renames the file at oldpath to newpath

Your system should support persistence and crash recovery.

Files should remain there after you quit the file system and restart it. You file system may be terminated illegally, e.g. ctrl-c is pressed. This may leave the system in an inconsistent state. You should be able to detect such inconsistent states and recover from them when the file system restarts. While writing the functions you should take care of the order of operations to maintain consistency in the file system.

Useful resources

http://www.cs.nmsu.edu/~pfeiffer/fuse-tutorial/unclear.html
http://fuse.sourceforge.net/doxygen/structfuse__operations.html
Man Pages

Bonus:

You may improve your fs with more features. There are the following extra-credit suggestions:

static int fs_chown(const char * path, uid_t uid, gid_t gid)
static int fs_chmod(const char * path, mode_t mode)
static int fs_utimens(const char * path, const struct timespec tv[2])


UFS: Submission

What to submit:

Your polaris ufs directory should contain the following files at minimal:

1. README
   README file should contain yourname/Clarkson Id, and a guide to the rest of the files. What functionalities have been implemented and the bug list.
2. Writeup
   You writeup should describe how you implemented fs_getattr(), fs_readdir(), fs_create(), fs_open(),fs_read(), fs_write(),fs_truncate(),fs_unlink(),fs_rename() and u_fschk(). What all things you considered while exporting this functions in your file system. Particularly, you should explain how you take care of the order of operations to maintain consistency in the file system in case of crashes.

Here is some optional food for thought:


• What is the largest file you can create in your file system?
• What is the largest number of files?
• What is the largest number of directory it can support? How many subdirectory it can support?
• If we reduce the block size, we also reduce the size of the bit map and the root directory
  How do the answers to the above questions change with a block size of 1024? 8192?

Where to submit:

scp userfs/* yourname@polaris.clarkson.edu:/afs/cu/class/cs444/sp14/ufs/yourname

When to submit:

Due on Friday Midnight 4/12/2013