Assignment 2 (due
Friday, 13 October, 10 pm)
In
this assignment, you will be modifying an existing storage server to make it more efficient.
This assignment must to be done in groups of two. If you are without a partner,
get in touch with me during class. The storage server has been written in java,
and you have to add code, without significantly changing the existing one.
What
to do?
Part I: Modify the
server to handle parallel requests
In the first part of this assignment, you
will add popup threads to the existing storage server. The current
implementation of the storage server processes incoming requests for operations
on storage units sequentially. To allow the storage server to process requests
in parallel, you must add popup threads to the storage server. This should be
done without changing the storage server's interface.
Each time a new request arrives, the
storage server should spawn a new thread to process it. Thread pooling is
another option, which is preferable for better performance, but its
implementation is not required for this assignment. A basic implementation of
popup threads should be incorporated in the storage server code that is
provided to you. For help on threads refer to the online
java tutorial .
Part II: Implement a
Disk Scheduling Algorithm
The current implementation of the storage server stores data and indexes in files. These files are accessed through the file system. You must replace some of these file accesses with raw disk accesses (using a disk simulator). You must replace only the read and write accesses to the files that store the data contained in data storage units. Do not replace index file and directory storage unit accesses. (We will pretend that the index files and the contents of the directory storage units are cached so that we do not have to go to disk. In fact, this assumption makes sense, because the operating system does indeed cache files). Since the disk simulator does not transfer any data, you should not really replace the original file accesses. Instead, you should just add calls to the disk simulator. A storage unit request is not a disk access request. You should keep track of the disk location(s) of data storage units. You should map every data storage unit access request to a series of disk sector accesses. Your disk scheduler must schedule these disk sector accesses. You may assume that data storage units are never deleted. (In fact the current implementation of the storage server does not really delete storage units.) That is, you do not have to reuse free disk space. To obtain good disk performance, you must schedule incoming disk access requests in a sensible manner. Check out the disk scheduling algorithms in Silberschatz and Gavin (Chapter 13). Doing something interesting in this regard will be rewarded in the grading.
The
disk Simulator
The disk simulator simulates an
HP 97560 disk drive. The interface to the simulator is quite simple and is
described in comments to the source code. The disk simulator package disksim consists of two files,
BlockingDiskModel.java and DiskModel.java. You should use only the methods
provided by BlockingDiskModel.java.
The disk simulator is a state machine that responds to disk access requests. Each request specifies a sector offset on the disk and the number of sectors to read or write. The simulator translates the offset to a physical disk address. Next, it computes the amount of time needed to
· Select the right disk head
· Move to the required cylinder (seek time)
· To wait for the appropriate sector to appear under the head (rotational delay/latency time)
· To transfer the data to or from the disk (transfer time)
The simulator does not transfer any data! It only computes the time t that it takes to perform a given disk request. The thread that invokes the disk simulator is put to sleep for this amount of time. Since the simulator does not actually transfer data, you must also perform the file accesses performed by the original implementation, or else you cannot read back the data written to a storage unit.
The disk simulator can be run in three modes. In the debug mode, each disk access is logged to a file. In the statistics mode, only summary statistics are logged to a file (#reads, #writes, total time, etc.). In the default mode, no data is written to file. The debug and statistics mode can help you in determining the performance of your disk scheduler and we will use these modes to evaluate your disk-scheduling algorithm.
Do not modify the code in package disksim (DiskModel.java and BlockingDiskModel.java). Your storage server will be tested with the original version of the disk simulator package.
How to proceed with the project?
It is advised that you begin work on this assignment as soon as possible, since it is significantly tougher than the previous one. As a first step go through the code and understand the different modules and how they work. Based on this you should decide where you want to add the popup threads and the disk access code. You should also think about how you would go about testing the correctness and efficiency of your design. Before you proceed any further, remember to run the test programs that are provided in the code for the storage server.
What to submit?
You should submit the following things as a part
of this assignment.
1.
The java code for the files you “modified”.
2.
A file called README.txt where you give a
tutorial on how to compile and run the modified storage server. This file should also contain the names,
netids and cornellids of all the individuals in the group.
3.
A file called DESIGN.txt where you explain your
design and why you chose it. It should also outline the way your code works.
How
will you be graded?
The following will play a crucial role in
your grades for this assignment.
1.
Correctness
of the storage server implementation.
2.
Robustness
and Efficiency of the storage server implementation.
3.
Clarity of the java
programs (comments!!!).
4.
Ease of using the README to test your
programs and results.
Storage Server Code and
Documentation?
Storage server code and its documentation…
The storage server code has a debugging option. By default, this option is disabled, but you can enable it by setting debugging in Debug.java to true. When you do this, the storage server will print debugging information.
To run the storage server, compile and run Server/ServerStart.java in one window. This will start the server process. When you start the server, you must pass (as a command-line argument) a directory in which the server can store its files. The storage server program sits in a loop, waiting for incoming requests from clients. To stop the server, hit Control-C.
The code comes with two examples/tests. The first example allows you to test the storage server's functionality without any clients. This test program is stored in TestServer/TestServer.java. Compile this file and run it.
To test if communication between a client and the server works ok, you need to compile and run two programs. First compile and start the storage server as described above ("Running the storage server"). Next, compile and run (in a separate window) TestClient/TestClient.java. This is a simple client program that communicates with the storage server.