CS4411
Practicum in Operating Systems

Project 6: File System

Disk handler implementation

What arguments does the disk handler have? How should I install the disk handler?

The disk driver code (disk.[hc]) sends a disk interrupt after a read/wite request is processed. The disk interrupt is processed by the disk handler that receives an argument of disk_interrupt_arg_t type. The disk handler is installed using install_disk_handler function. Before sending requests to a disk, the disk should be created using disk_create function.

Read/Write disk operations

How does the minithread system send write/read operations to the disk driver? How does the minithread that asks a disk operation behave?

A minithread initiates a read or write block operation using the disk_write_block or disk_read_block functions. The disk operation request is assigned an I/O structure. The I/O structure is used in the disk handler to wake up the blocked minithread that waits for the result of the request.

Size of directory

Would limiting the size of a directory to 1 data block limit the size of directories too much?

Yes, this is an unnecessary restriction. Your directories should accomodate any number of entries.

Number of INODEs per data block

When storing inodes, do we want to fit as many inodes as possible into a data block, or allocate one inode for each data block?

This is a design question, and by project 6, these types of questions are up to you.

But let me reiterate the design principles to keep in mind:

  • You will want to design a system whose implementation is not overly complex. If it isn't working by the deadline, it might as well not exist.
  • You will want to store the inodes in a place where you can readily find them.
  • You will want to avoid wasting space.

So, if I were you, I would initially place each inode on a separate block. This wastes space, but calculating the location of an inode is a breeze. Once this works, you can modify the filesystem to pack N inodes into a single disk block.

mkfs Behavior

How should I structure my mkfs executable?

We'd like to be able to automatically use your mkfs (so that we can give you a clean slate between tests). Please allow us to be able to be able to call it like:

mkfs 1000 FILE

which creates a disk drive of size 1000 blocks with the name FILE.

You should add the following code near the bottom of your Makefile so that we may build mkfs.exe independent of the man minithreads program:

MAIN = mkfs
mkfs.exe: start.obj end.obj $(OBJ) $(SYSTEMOBJ)
     $(LINK) $(LFLAGS) $(LIB) $(SYSTEMOBJ) start.obj $(OBJ) end.obj /pdb:"mkfs.pdb" /out:"mkfs.exe"

We have specified that you append a file name, but you will not have to load arbitrary disks in your OS. The file parameter to mkfs is just so that we can save the disk where we would like (in case we need to inspect it later).

Path Component Size

Do you really mean to say that we must make all paths at least 256 characters?

No. You must be able to support 256 characters, but we must also be able to create the path /a.

Cursors

In the slides it says to maintain a separate cursor for each thread. Do we really have to do this? Is this what a normal OS does?

This is a typo on our part. Slide 15, "Semantics of files" should read that one cursor is maintained per opened file.

Initializing the filesystem

Does the initial cd initialize the filesystem?

This comment is another typo left over from previous years. The mkfs program should do the initialization of the filesystem.

It is acceptable to delay starting the disk until the first filesystem operation, but this is by no means an optimal design.

Powered by Firmant