1 Introduction

In this assignment, you require to experiment with computer system measurements. At first, pick a platform to study. Any Unix-based system (such as a PC running some version of Linux) is acceptable (no Windows-based systems please). Secondly, perform some simple experiments, which you design to bring out various properties of the file system under test. Thirdly, generate plots to demonstrate properties – call them “empirical proofs”. At last, prepare up what you did.

2 Problem

In this assignment, we shall explore inner-workings of the file system. In a Unix based file system, suppose we have the following system calls to work with: open(), close(), read(), prepare(), lseek(), and fsync(). Use man pages to find more information about working of these calls.

The assignment is based on writing code snippets which help in measuring time taken to do a variety of file system operations.

Step1. Platform. Choose a Unix-based platform to work on. This may very likely be something like a PC running Linux, but feel free to experiment with whatever system you have access to, e.g., FreeBSD, some old UNIX system like AIX, or even Mac OS X. However, it should be a Unix-based system.

Step2. Timers. The accuracy and granularity of the timer the is being used would have a large effect on your measurements. Hence, you must use the best timer 1available. Fortunately, on x86 platforms, a highly correct cycle counter is already available. The instruction to use it is known as rdtsc, and it returns a 64-bit cycle count. By knowing the cycle time, one could easily convert result of rdtsc into useful time.

First thing is to figure out how to utilize rdtsc or its analogue (you could use Google to determine more about it). Then, you require to get a cycle count, convert the result into seconds and measure how long something takes to run (e.g., a program which calls sleep(10) and exits must run for about 10 seconds). Confirm whether results make sense by comparing them with the less correct but reliable counter like  gettimeofday. Note that confirmation of timer accuracy is highly significant.

Step3. Measuring the file system. After getting the timer in order, measurements have to be recorded for the file system which is being used. All measurements must be taken on the local disk of some machine, Do not measure performance of a distributed file system, like, the CSE home directory. If you aren't using your own machine, you may consider Linux Lab in which case you may want to work in /tmp.

The experiments which are designed must address the following problems.

1. How big is the block size used by file system to read data? use reads of varying sizes and plot the time it takes to do such reads. Also, be wary of prefetching effects which often kick in during sequential reads.

2. During a sequential read of a large file, how much data is prefetched by file system? Time each read and plot time per read.

3. How big is the file cache? Repeated reads to a group of blocks that fit in cache would be very fast; repeated reads to a group of blocks that don't fit in cache would be slow.

4. How many direct pointers are in the inode? Think about using prepare() and  sync() to answer this problem. Or use read(). Also, think about what happens when you extend a file and all of a sudden an indirect pointer has to be allocated – how many more prepares happen at that point?

In the prepare-up, there must be one or more plots that help answer the problems above. Also, try to critique the answers by posing problems like, are the conclusions you draw foolproof? Or are they simply hypotheses? A main issue with any data collection is, how convincing are the numbers? How does one deal with experimental noise? etc. You must use repetition to increase the confidence, like, take multiple measurements of an event, and find out (for ex) an average over many runs instead of the result from just a single experiment.

Step 4. Writing it up. After the experiments, follow the below mentioned format to prepare the paper (report).

1. Title: The title must be descriptive and fit in one line across page.

2. Author: This must be right under the title, says who you are.

3. Abstract: This is the paper in brief and must state the basic contents and conclusions of the paper. In general, the abstract is an advertisement which  must draw the reader into reading your paper, without being misleading. It must be complete enough to understand what would be covered in the paper. Do not be afraid of giving away the ending!

4. Intro: This is a brief overview of what you did, and what you learnt. This must contain more motivation than the abstract. Again, ensure you include your main conclusions.

5. Methodology: This must answer problems like, what you measured in the file system and how you went about doing it. Include something about your timer accuracy, as well as a description of the platform you used to the level of detail such that someone else can reproduce the similar experiments elsewhere.

6. Results: This section must mainly consist plots, each addressing the problems above. Ensure that graphs have axes labeled (including units).

Also include code snippets with each plot (or some rough description of the methodology used to conduct the experiment) so that the reader could follow your idea. This must be followed by conclusions for each of the plots.

7. Conclusions: Summarize the conclusions here, and discuss things you have learnt during this experimentation.

Note. This paper (report) should be at most 6 pages long (including everything), in 10 point, double column format.