Operating Systems Project 6

The goal of this project is to familiarize yourselves with file system design and implementation.

As before, this is an individual or group project.

Description

I want you to design a file system that can store up to 10,000 files on a medium up to 2GB in size. The maximum size of each file is 200MB. The file system should provide a directory tree with file names composed of arbitrary characters up to 200 bytes long. Each block is 1KBytes, which means files and the file system must be able to haandle up to 2M-1 blocks (2,097,151 blocks, with at least 21 bits per block number).

The file system does not have to be efficient. In particular, you do not need to implement a buffer cache. Your implementation must limit itself to using a fixed size of storage, on the order of 1MB or (much) less. The actual storage must be moderately efficient, so that most of the space on the "disk" should be available for storage of actual data.

The file system should use block read and write operations provided by the instructor:

typedef char block [1024]; /* each block is 1KB */
int read_block (int block_num, char * block) --- returns 0 if the operation is successful, and -1 otherwise
int write_block (int block_num, char * block) --- returns 0 if the operation is successful, and -1 otherwise. Actually writes the block to disk
int dev_open () --- returns the device size (in blocks) if the operation is successful, and -1 otherwise

These are implemented in block.c. The first block is block number 0.

dev_open accesses blocks in a file named simulated_device in the current directory. To create the file, use the following command:

dd if=/dev/zero of=simulated_device bs=1024 count=x

where x is the size (in blocks) of your intended device. For example,

dd if=/dev/zero of=simulated_device bs=1024 count=131072

gives you a 128MB device (128K blocks), and

dd if=/dev/zero of=simulated_device bs=1024 count=250000

gives you a device large enough for the maximum file size that testp6 (see below) tries to build.

Your code must implement the following API, inspired by and simplified from the POSIX file API:

int my_open (char * path), to open an exisiting file for reading or writing
int my_creat (char * path), to open a new file for writing only (fails if the file already exists)
int my_read (int fd, void * buf, int count), to sequentially read from a file
int my_write (int fd, void * buf, int count), to sequentially write to a file
int my_close (int fd)
int my_remove (char * path)
int my_rename (char * old, char * new)
int my_mkdir (char * path), only works if all but the last component of the path already exists
int my_rmdir (char * path)
void my_mkfs (), checks to see if the device already has a file system on it, and if not, creates one.

A file providing this API, but not implementing it, is available at p6.c. If you only modify this file, that is all you have to turn in, otherwise turn in all your files for this project. For your convenience, I have also provided p6.h and a very simple test program, testp6.c. This program runs all the tests unless an optional argument is provided, in which case it runs all the tests on files whose size (in bytes) is less than or equal to the argument. A log of a complete run is here.

Your code does not need to provide protection, multiple links, access times, or current directories. You also may assume that each file will be opened at most once before it is closed again, although multiple files (up to 10) may be open at the same time.

Your code does need to handle "/"-separated paths of arbitrary depth, and so one useful function you may find yourself writing may be to parse paths. You may also want to write some routines to maintain and access bitmaps on disk. Of course, all code you turn in must be yours, but you may draw inspiration from other code (e.g. Minix 3) as long as you give credit where appropriate.

All your code should run on a Unix compatible system. You may use uhunix or uhunix2, or esb-course, or any Linux system. Please let me know what you have used, and also let me know as far in advance as possible whether you are planning to use esb-course.

You MUST consult with the instructor as early as possible (preferably before April 20th) to discuss your design and your strategies for implementation. You MUST you have at least your data structures defined, both on disk and in memory, before you come in to discuss your design.

To read what is stored on your "device", you may run

od -t x1 simulated_device | m

If you run on a little-endian machine (such as intel architectures), your numbers will come out "backwards", i.e. with the LSB first, unless you convert to big-endian before saving on disk (not particularly recommended).