FileSystem Object

Nachos supports two different filesystems, a ``stub'' that simply maps Nachos file operations into ones the access Unix files in the current directory, and a Nachos file system that users can modify. Use of the stub filesystem makes it possible to implement paging and swapping before implementing a Nachos file system. The -DFILESYS_STUB compilation flag controls which version gets used.

The FileSystem object supports the following operations:

FileSystem(bool format)

For the stub system, this constructor (and destructor) does nothing; the Unix file system is used instead. For the Nachos file system, format indicates whether FileSystem should be re-initialized or whether the previous contents of the file system (from an earlier Nachos session) should be retained.

The FileSystem constructor is called once at ``boot time.'' It assumes that a synchDisk instance has already been created and uses it to store the file system.

bool Create(char *name, int initialSize)

creates a zero-length file called name. If the file already exists, Create truncates its contents. Note that Create returns a boolean value, either success or failure, but does not actual open a file; it simply makes sure that it exists and has zero-length. To actually write to a file that has been created, a subsequent call to Open must be made.

Argument initialSize specifies the actual size of the file. (Note: initialSize is ignored in the stub filesystem; Unix doesn't require that a file's maximum size be specified at the time it is created.) For the regular filesystem, specifying the file's size at creation time simplifies implementation. Sufficient disk sectors can be allocated in advance to hold the entire (potential) file contents, and appending data to the file requires nothing more than accessing the appropriate blocks. Of course, one possible variation for the assignment is to implement extensible files whose actual size grows dynamically.

OpenFile *Open(char *name)

opens file name for subsequent read or write access. In the stub file system, Open simply opens the Unix file for read/write access. Note that all files opened under Nachos are opened with both read and write access. Thus, the user opening the file must have write permission for a file even when the file will only be read. One consequence of this can cause confusion while implementing multiprogramming. Nachos is unable to Exec binary files that are not writable because it cannot open them.

Another thing to note is that Open does not truncate a file's contents (it can't since you might be reading the file). However, when writing a file, it is sometimes the case that the file's existing contents should be deleted before new data is written. In Nachos, invoking Create before Open insures that a file is zero-length.

bool Remove(char *name)

deletes file name and frees the disk blocks associated with that file.

Note that in Unix, the disk sectors associated with a deleted file are not actually returned to the free list as long as there are any processes that still have the file open. Only after all open file descriptors for a file are closed does Unix deallocate the disk blocks associated with the file and return them to the free list. The Unix semantics prevent certain types of undesirable situations. For example, deleting a binary file cannot cause processes paging off of that file's text segment to terminate unexpectedly when the paging system attempts to load an instruction page from non-existent file.

One suggested Nachos assignment is to provide Unix-style file deletion.