In this project, you will implement a tiny file system on top of a virtual disk. This file system is called TinyFS which is similar to the Unix file system discussed in the class notes. This virtual disk is actually a single $4$MB file that is stored on the real file system in our lab.

Disk Emulator

We provide you with a disk emulator on which to store your file system. As mentioned before, this virtual disk is actually stored as one big file in the file system, so that you can retrieve data in a $$disk image$.$ In addition, we will provide you with some sample disk images that you can experiment with to test your file system. Just like a real disk, the emulator only allows operations on entire disk blocks of $4$KB $($DISK BLOCK SIZE$).$ You cannot read or write any smaller unit than that. The primary challenge of building a file system is converting the user$$s requested operations on arbitrary amounts of data into operations on fixed block sizes.

The interface to the simulated disk is given in disk.h:

#define DISK$\_$BLOCK$\_$SIZE $4096$

int disk$\_$init$($ const char $*$filename$,$ int nblocks $)$;

void disk$\_$read$($ int blocknum, char $*$data $)$;

void disk$\_$write$($ int blocknum, const char $*$data $)$;

void disk$\_$close$()$;

Before performing any sort of operation on the disk, you must call disk init and specify a $($real$)$ disk image for storing the disk data, and the number of blocks $($i$.$e$.1024$ in this project$)$ in the simulated disk. If this function is called on a disk image that already exists, the contained data will not be changed. When you are done using the disk, call disk close to release the file. These two calls are already made for you in the $2$ shell, so you should not have to change them. Furthermore, as the names suggest, the functions disk read and disk write read and write one block of data on the disk. Notice that the first argument is a block number, so a call to disk read$(0,$data$)$ reads the first $4$KB of data on the disk, and disk read$(1,$data$)$ reads the next $4$KB block of data on the disk. Every time that you invoke a read or a write, you must ensure that data points to a full $4$KB of memory.

File System

Using the existing simulated disk, you will build a working file system. Take note that we have already constructed the interface to the file system and provided some skeleton code. The interface is given in fs$.$h:

void tfs$\_$debug$()$; int tfs$\_$delete$($const char $*)$

; int tfs$\_$getsize$($const char $*)$;

int tfs$\_$get$\_$inumber$($const char $*)$;

int tfs$\_$read$($ int inumber, char $*$data$,$ int length, int offset $)$;

The various functions must work as follows:

$$ tfs debug $-$ This function scans a file system and reports on how the inodes and blocks are organized. Once you are able to scan and report upon the file system structures, the rest is easy. Your output from tfs debug should be similar to the following:

superblock:

signature is valid

$26$ blocks in use

$4$ inodes in use

root inode $1$:

size: $4096$ bytes

direct blocks: $2$

foo inode $2$:

size: $13$ bytes

direct blocks: $3$

bar inode $6$:

size $81929$ bytes

direct blocks: $1011151718$

indirect block: $23$

indirect data blocks: $303942...$

$$ tfs delete $-$ It deletes the file specified by the parameter. Release all data and indirect blocks assigned to this inode and return them to the free block map. On success, return $($positive$)$ inode number. On failure, return $0.$

$$ tfs getsize $-$ It returns the logical size of the given file, in bytes. Note that zero is a valid logical size for a file. On failure, return $-1.$

$$ tfs get inumber $-$ This function searches the root directory entries and returns the inode number of the given file. On failure, return $0.$

$$ tfs read $-$ This function reads data from the specified inode number inumber. That is$,$ the user who calls this function needs to get the inode number via tfs get inumber first. This function copies "length" bytes from the inode into the "data" pointer, starting at "offset" in the inode. The total $3$ number of bytes read will be returned. The number of bytes actually read could be smaller than the number of bytes requested, perhaps if the end of the file is reached. If the given in umber is invalid, or any other error is encountered, return $0.$

It$$s quite likely that the file system module will need a number of global variables in order to keep track of the currently file system. For example, you will certainly need a global variable to keep track of the current free block bitmap, and perhaps other items as well. In the context of operating systems, they are common and quite normal. Furthermore, the file system has to maintain state persistently. You need to write all modifications, such as the inode block, superblock, etc., back to disk.

Shell Interface

After you extract the source code, build it with make. We have provided for you a simple shell that will be used to exercise your filesystem and the simulated disk. When grading your work, we will use the shell to test you