Added OS II assignments

OSU Coursework/CS 444 - Operating Systems II/Kernel Assignments/Project 2/questions.tex

@@ -0,0 +1,19 @@
+\section{Questions}
+\subsection{Point of Assignment}
+The point of this assignment was to explore the way that elevator algorithms are implemented as well as getting acquainted with going through all the steps needed to make and apply changes to Linux kernel modules. This required looking through the kernel elevator source files and performing research to determine how to adapt our elevator algorithm. Additionally, this assignment was an initial experience creating a patch for the Linux kernel.
+
+\subsection{Problem Approach}
+We approached this problem by first reading through the Homework 2 page on Canvas and reading through the information on the noop and LOOK/CLOOK algorithms on the "I/O and provided functionality" page on Canvas. Next the "noop-iosched.c" file was copied to "sstf-iosched.c" and all references to noop were changed to sstf. Research was then performed to figure out how to get the kernel to compile, recognize, and use this scheduler. The "noop-iosched.c" file and the files it is dependent on were also explored to learn how this scheduling algorithm was implemented.
+
+After this initial set-up and research, it was decided to implement the LOOK algorithm because it is the more efficient algorithm that seemed like a better choice, especially in real world use cases. In order to ensure that the queue is sorted, insertion sort is used for each of the new items added. Printk statements were placed in the queue add function to ensure that printed results of the queue's state matched what was expected from the LOOK algorithm.
+
+\subsection{Correctness}
+We know that the end result was correct by using the output of the printk function calls mentioned above to log the blocks for each request as they were added and dispatched. We also added printouts of the whole queue each time an entry was added, to ensure that the entry was placed in the expected location. With these statements on the screen, verifying correctness was as simple as making sure block numbers in the queue were being added in such that if the head were on its way "up" or "down", that the data in the queue matched the current direction.
+
+To ensure that the implementation worked for all reasonable accesses of the drive, a python script was written to generate many randomly sized files, as well as to randomly read this data back. By changing the number of times that the randomly generated files were read/written we were able to test the scheduler until varying scenarios of use. 
+
+\subsection{What Was Learned}
+We learned that documentation is extremely important to code development as it allows readers to more easily use code that has already been written. There are not many comments in the "noop-iosched.c" or the "elevator.c" file to describe how the various functions work, and this made it difficult to understand exactly how the previously written code functioned. We also learned that it can be challenging to debug while working with the kernel because sometimes the only error that you see is that the kernel does not boot, at which point using the GDB debugger is needed.
+
+\subsection{How to Evaluate}
+After applying the patch file, building the kernel, and booting the VM, you should be able to see prints to the screen once the scheduler is loaded and applied to the main boot device /dev/hda. At this point, there were be a few different kinds of statements to look out for. The first will start with "[SSTF\_GROUP4] Adding ...." that will tell you when a new item is being added to the queue, what block number the access is for, and whether this is a read or write. After these add prints there will be a printout of the whole elevator queue that will immediately allow you to see where the new entry was placed in the queue. Once the system is ready for a dispatch, the kernel will also print a statement starting with "[SSTF\_GROUP4] Dispatching:..." telling you what block is being dispatched, and whether it's a read or write. By watching changes to these statements as the kernel is booting, or by using a program to generate IO, correctness of the implementation can easily be verified. We have included the python file io\_test.py in our tarball if you want to use it to generate the IO that we did for testing.