Tips for NACHOS Assignment 4

Under Construction

This document is currently incomplete.

Building a File System

Assignment 4 is to be done inside of the directory code/filesys.

NOTE: The Makefile for this assignment probably needs to be modified to reflect the changes that you've made to the system in assignments two and three. For most groups you'll probably want to delete the definition of THREADS and add the definition for USE_TLB (in code/filesys/Makefile). The resulting DEFINES should look like:

        DEFINES =-DUSER_PROGRAM -DVM -DUSE_TLB -DFILESYS_NEEDED -DFILESYS

I've also compiled the standard (original) version of the filesystem in /cs/course/4321/code/filesys which you should be able to execute to check if you "baseline" system is working properly. Remember that you won't be able to execute Nachos in that directory because it needs to create and write to a file named "DISK" in the current directory. Instead copy Nachos to one of your directories and try it out.

A Possible Strategy

Before you Start

Read all of this document first.

Have a look at the the Nachos Roadmap document. In particular the following sections should prove useful:

Understand what the current implementation does: how file headers and the directory are implemented, how a file is organized, how free blocks are maintained and organized as well as how FetchFrom and WriteBack work and why they are used/needed.

You should also examine and understand the current implementation of the filesystem related classes before you start to modify any code.

A Special Note on Why Your Programs May have Stopped Working

In the previous assignments the file system has been simulated using the UNIX file system. This meant that when a user program called Read or Write it "held" for the duration of the entire underlying UNIX read or write call. Now that the real Nachos file system is being used a user program that causes any type of disk operations (e.g., page faults, calling Read/Write/Open/Create) will be blocked waiting for the completion of the disk operation. While that user program is blocked another user program may be run.

NOTE: these types of problems should only be caused when you have multiple user program executing concurrently. If you have this problem then it's very likely that you have bugs in the implementation of your previous assignments.

You can:

Fix these bugs. Which may be very time consuming and will not contribute to this assignment in a tangible way.
Do this assignment without running multiple programs.

You may wish to reread the tips on Improving the File System Simulation from the previous assignment.

Getting Started

Decrease the size of your swap space to the maximum file size permitted by Nachos (MaxFileSize in filehdr.h) compile Nachos in the code/filesys directory and try to run a few very simple and very small programs. MaxFileSize is defined in code/filesys/filehdr.h.
```
       #define NumDirect   ((SectorSize - 2 * sizeof(int)) / sizeof(int))
       #define MaxFileSize (NumDirect * SectorSize)
```
Given the definition (shown below) of SectorSize this means that until you modify (fix) the filesystem your swap file is limited to 30 * 128 = 3840 bytes.
The disk parameters are defined in code/machine/disk.h. It's likely that these values won't have to be changed to run your programs.
```
       #define SectorSize      128     // number of bytes per disk sector
       #define SectorsPerTrack 32      // number of sectors per disk track
       #define NumTracks       32      // number of tracks per disk
       #define NumSectors      (SectorsPerTrack * NumTracks)
                                       // total # of sectors per disk
```

Try out a few of the simple Nachos options related to the filesystem. NOTE: before you can the other commands you must first format the Nachos disk. Formatting the disk create a UNIX file in your current directory named "DISK".

       FILESYS
         -f causes the physical disk to be formatted
         -cp copies a file from UNIX to Nachos
         -p prints a Nachos file to stdout
         -r removes a Nachos file from the file system
         -l lists the contents of the Nachos directory
         -D prints the contents of the entire file system
         -t tests the performance of the Nachos file system

Now reformat your Nachos disk
```
        ./nachos -f
```
Copy the halt program from the UNIX disk to your Nachos disk
```
        ./nachos -cp ../test/halt halt
```
Run the halt program from the Nachos disk
```
        ./nachos -x halt
```
Copy other programs to the Nachos disk and make sure that they also run.
Keep in mind where the weaknesses in your previous assignments might be when determining where to start for this assignment.
If you are not absolutely sure that your multiprogramming implementation is bullet proof and will continue to work correctly now that a program will block (and something else will run) while waiting for I/O. You might wish to do the part of the assignment that makes your file system "atomic" and "serializable" towards the end.

You may find it necessary (or helpful) to add support for two new system calls (defined in code/userprog/syscall.h).

       /* Remove a file from the file system.
        * Returns success (1) or failure (less than 0)
        */
       int Remove(char *name);
       
       /* Move the read/write file offset to the specified position.
        * If successful it returns the new position otherwise it returns
        * a failure code (less than 0)
        */
       int Seek(OpenFileId id, int newpos);

Remember that to do this you'll need to add some assembly instructions to code/test/start.s and to add a new definition for these calls to code/userprog/syscall.h.

Things to Remember (Gotcha's)

Part 2 and 3 of the assignment can probably be done at the same time (as part of the same design).
You should be able to use your RWlock class from the first assignment to help make the file system "atomic" and "serializable".
The SynchDisk object only synchronizes data that is being written to or read from a sector.
Remember that you probably want to build extensible files in such a way that bytes that aren't actually written to a file won't actually be stored in the file (this will be made more clear in class).
Devise a plan for the assignment. Your may be better off doing a good job of a smaller subset of the assignment than a mediocre or poor job of the entire assignment.
Think about testing! Plan your testing!
Use the "DEBUG" and "ASSERT" statements they should help you to find problems with your implementation.
Program defensively. A good (production quality) operating system should be completely bullet proof. Your OS doesn't need to be quite that strong - but it should have no GLARING holes.
See the notes on Assignment One for other "Things to Remember" and for how to hand in the assignment.
See the notes on Assignment Two for other "Things to Remember".
See the notes on Assignment Three for other "Things to Remember".

Modified: Nov 18, 1995
Created: Nov 18, 1995