Description

For this assignment you will implement a virtual block device, with the intent of lying about the underlying device.You will also implement a small test application to demonstrate your virtual device. You are to implement this pseudo-device using your operating system of choice, but you will need to make it as flexible as possible (as you will build upon this for a later assignment) ... so I strongly recommend implementation as a loadable kernel module rather than rebuilding the kernel with each revision. For linux, start with a look at loadable kernel modules, and for BSD I'd suggest looking at "ccd," but I leave it up to you as to where you choose to create the device (though the requests you pass through should go to a raw interface ... though I realize that doesn't always mean you've bypassed the cache :) For simplicity during development, consider the use of a loopback device to use a file as the underlying block device.

The pseduo device must satisfy the following main requirement:

• It should be easy (e.g., through substituting one code routine) to modify the mapping of block numbers. The call you will be modifying is the "strategy()" routine for your block device driver (this is called "make_request()" under Linux), and modifying the mapping means changing the re-numbering for incoming requests that this routine performs.
• The redundant form of this pseudo-device simply passes on block requests, but I'd also like you to remap every request for block n to block f(n) where the function f(n) can be any arbitrary 1-to-1 mapping, based on a configurable device block size that is independent of the incoming requests.
• Extra credit: Maintain a table of mappings and reserve space to store this table on the underlying device. This is what you'd need to do for your mappings to be persistent.

The Test Application

To test your pseudo-device you will need to run a program that reads and writes blocks of data. Specifically, you should write two programs, one that sequentially reads all the blocks on the device, and another that reads them in an alternating pattern. Let's say your device is N blocks in capacity, then the first program will take N as a command line parameter. The second program will take an additional parameter K, and will read all blocks in the following order:

0, N/K, 2N/K, 3N/K, .... (K-1)N/K, 1, 1+2N/KY, 1+3N/K, ... etc.

You'll notice that this is a very bad sequence of block requests for most block devices, (how bad may depend on the choice of K).

Testing & Results Presentation

• You will show that your device is usable by the test programs (demo and submitted code + README)
• You will time the applications for increasing values of N, and multiple choices of K (e.g., 4, 32, 128), and plot their duration for both your pseudo-device, and the underlying device on its own (in other words ... plot a graph and show me if your pseudo device has placed much delay on the system) ... for this test your pseudo-device should simply map a block to its same value.
• Perform the last test again, but with a mapping that remaps block X to (N-X-1).

What to submit?

You must submit your source code (your new kernel files, your applications, etc) and a readme file explaining your design decisions and detailed instructions for testing. You will be required to make appointments to demostrate your system.

You should also submit the graphs you plotted based on timing the test applications (line graphs are suggested for this purpose).