View source for Assignment: Ultra-Tiny File System

[[Category:Student Built Xinu]]
= Ultra-Tiny File System =
This assignment is a [[Xinu]] assignment allowing the student to more firmly understand how an operating system works. This assignment is part of the [[Student Built Xinu]] track for professors that are [[Teaching With Xinu]]. The entire working directory containing your Xinu operating system will be submission for this assignment.
== Preparation ==
First, make a fresh copy of your work thus far.
   cp -R <old Xinu directory> <new Xinu directory>
Untar the new project files on top of this new directory:
   tar xvzf <tar-ball directory>
You should now see the new project files in with your old files. Be certain to <code>make clean</code> before compiling for the first time.

== Non-blocking ttyRead() ==
To synchronize complex communications properly, it often helps to be able to "peek" at an I/O device without having to block. Add non-blocking read as an option to your TTY driver. Use the <code>iflags</code> field (which should be fetched or set with the <code>ttyControl()</code> function). Your <code>ttyRead()</code> function should check the flags and the count of the input semaphore before each call to <code>wait()</code>. If it looks like the call might block, return the current count of characters instead.

== The Disk Driver ==
The project tarball equips Xinu with a block I/O device driver (running over the second serial port) that speaks to a <code>xinu-disk</code> program running on your computer. The <code>xinu-disk</code> process maps reading and writing requests from the backend to a locally-stored disk file. In this way, your O/S can behave as though it has a small (64K) disk attached, and the storage is really a file in your home directory.

See below for additional details on the <code>xinu-disk</code> command.

== The File System ==
The project tarball includes a partial implementation of a small file system. The first block of the "disk" is expected to contain a '''superblock''' which contains vital bookkeeping information about the file system, such as:
* A pointer to a list of free disk blocks,
* A pointer to a master directory index,
* Block size, disk size, etc., and
* A magic number, so that it can tell the difference between a blank disk and an initialized disk image.
The new header files <code>disk.h</code> and <code>file.h</code> contain the necessary constants and structures to build the file system. Take a look at <code>disk/disk*.c</code> (disk driver source code,) <code>file/file*.c</code> (file source code,) and <code>file/sb*.c</code> (superblock source code.)

Our disk has 256 blocks of 256 bytes each. The free disk block list is dynamic, but our directory index is limited to a fixed number of files, with fixed length names, and fixed maximum sizes. (The problems and solutions associated with these limitations would each make excellent final exam questions, by the way.)

You are to add file deletion (<code>fileDelete()</code>) and free block removal (<code>sbFreeBlock()</code>) into the system.

== Testing ==
Provide a main program that demonstrates that your <code>fileDelete()</code> and <code>sbFreeBlock()</code> calls are working properly.

The command "<code>xinu-disk</code>" starts up a disk daemon on the local server that can provide disk access to the selected backend machine via its second serial port. Build the disk daemon by running "<code>make xinu-disk</code>" in your <code>compile/</code> directory. For example, to test my file system on backend "Dask" using a local disk image called "foo.dat", I would run the command "<code>mips-console dask</code>" in one terminal, and then execute "<code>./xinu-disk foo.dat dask2</code>" in a second terminal within the first ten seconds of my Xinu kernel booting.

Xinu-disk's ability to synchronize with a "moving-target" backend is somewhat rudimentary -- you may occasionally see the handshake fail upon startup. Just close out the <code>mips-console</code> session normally, close the <code>xinu-disk</code> process with a "Control-C", and try again.

The command "<code>xinu-status</code>" will list the users on each backend, and "<code>xinu-status -c uart</code>" will list the users on each backend's second serial port. Also recall that a user can bump another user off of a specific backend after 10 minutes of activity.