Project 3: I/O Cache Emulator

The goal of the project is to develop a user-level IO cache emulator to investigate the impact of admission and eviction policies. To this end, you need 1GB of storage to represent your main storage. Moreover, you need to create a ramdisk as the I/O cache, with a maximum size of 64MB RAM. Your code will receive a set of accesses (trace file) and emulate I/O operations for each line of trace by reading from and writing to a file. Assume that each line of the input trace has the following format:

128166410318061256,wdev,3,Write,3156835840,4096,933

Where the elements represents:

timestamp, workload name, workload name, access type(read/write), address, size, offset

For each line, perform a read/write on a file at the address, with the size of the request. As mentioned above, the size of your main storage is 1GB, so first divide the address by 4096, and then take modulo (mod) of the address to the size of storage (1GB). You can ignore the other elements. Assume that the size of each cache block is 4KB. Each line of the input trace represents one I/O request.

You should provide a report with the following stats:

• Experiment-1: Report the response time of your main storage and ramdisk for sequential and random accesses (reads and writes separately). Generate the accesses synthetically.
• Experiment-2: Assume that ramdisk is the cache layer for the main storage, and each I/O request will be first admitted to the cache. Cache blocks that do not exist in main storage are written back to main storage on eviction. Implement LRU and FIFO policies and compare the response time. Also, report the cache hit ratio and the number of main storage and cache reads and writes. Do NOT flush the cache at the end of reading the input traces. Run the tests for cache sizes of 4MB, 16MB, and 64MB.
• Experiment-3: Conduct the Experiment-2 with synchronous I/O and compare the results.
• Experiment-4: Assume that the admission of blocks to the cache is conditional: the first time system faces an access to an address, it will bypass the cache and only captures its address. If that address is accessed again, then the block should be admitted to the cache. Conduct the experiment-2 with conditional admission and compare the results.

Testing

• You will receive a sample input in Element group. You can use it for your reporting the required stats in experiments 2,3,4. If your tests run too long, you may use a fixed percentage of the trace file. In that case, use the same percentage for all experiments. Do NOT use too low a percentage; allow the tests to stress your design.
• It is possible that you receive another input trace on the presentation day.
• Start with implementing simple parts and then add more features.
• Have functional tests for your implemented policies in case you cannot properly feed the trace into your design.
• Write a short report and evaluate the required metrics. Your report should be one pdf file. There is no limit on the page number. The quality of the report can affect your score.

Considerations

• The project is due on the 08.12.2025, 23:59 (hard deadline).
• Please be careful about writing the data on your main storage and don’t overwrite your own data!
• If you want a bigger trace file, send me a message.
• Attendance is mandatory on presentation day.
• The projects should be implemented in C.
• The evaluation is not All-or-Nothing, so start with simple steps.
• Both members of the group are required to present the code
• You are (obviously) allowed to implement more features, but you should prioritize the features we ask for!