Programming Assignment 4 Lab 4 IO Scheduling Professor Hubertus Franke CSCI GA 2250 001 Spring 2026 In this lab you will implement and simulate the scheduling and optimization of I O operations for a hard disk Applications submit their block IO requests bio to the IO subsystem Block Layer potentially via the filesystem where they are maintained in an IO queue until the disk device is ready for servicing another request The IO scheduler then selects a request from the IO queue and submits it to the disk device This selection is commonly known as the strategy routine in operating systems and shown in the figure below On completion another request can be taken from the IO queue and submitted to the disk The scheduling policies will allow for some optimization as to reduce disk head movement or overall wait time in the system The schedulers that need to be implemented are FIFO N SSTF S LOOK L CLOOK C and FLOOK F the letters in bracket define which parameter must be given in the s program flag shown below You are to implement these different IO schedulers in C or C and submit the source code Makefile make log and grade log as a single zip tar or tar Z which we will compile and run The same deductions for missing files or non requested files input outputs are assessed as in previous labs Invocation is as follows Only the s option is required The default scheduler is fifo if s is not supplied Options as usual can be in any order The input file is structured as follows Lines starting with are comment lines and should be ignored Any other line describes an IO operation where the 1st integer is the time step at which the IO operation is issued and the 2nd integer is the track that is accessed Since IO operation latencies are largely dictated by seek delay i e moving the head to the correct track we ignore rotational and transfer delays for simplicity The inputs are well formed iosched s schedalgo v q f inputfile io generator numio 32 maxtracks 512 lambda 10 000000 1 328 129 401 We assume that moving the head by one track will cost one time unit As a result your simulation can should be done using integers The disk can only consume process one IO request at a time Once a request is active on the disk it cannot be interrupted by any other incoming request Hence these requests must be maintained in an IO queue and managed according to the scheduling policy The initial direction of the LOOK algorithms is from 0 tracks to higher tracks The head is initially positioned at track 0 at time 0 Note that you do not have to know the maxtrack think SCAN vs LOOK Programming Assignment 4 Lab 4 IO Scheduling Professor Hubertus Franke CSCI GA 2250 001 Spring 2026 total time tot movement io utilization Each simulation should print information on individual IO requests followed by a SUM line that has computed some statistics of the overall run see provided reference outputs For each IO request create an info line 5 requests shown in the order of appearance in the input file 0 1 1 431 1 87 467 533 2 280 431 467 3 321 533 762 4 505 762 791 Created by printf 5d 5d 5d 5d n iop req arr time r start time r end time args IO op its arrival to the system same as from inputfile its disk service start time its disk service end time Please remember 5d is not 6d For C formatting refer back to lab2 and lab3 where similar outputs were created For the statistics of the simulation provide a SUM line note variables printed as lf are double floats Created by printf SUM d d 4lf 2lf 2lf d n avg turnaround avg waittime max waittime total time total simulated time i e until the last I O request has completed tot movement total number of tracks the head had to be moved io utilization ratio of time io was busy total time avg turnaround avg waittime max waittime 10 sample inputs and outputs and runit gradeit scripts are provided with the assignment on NYU brightspace Please look at the sum results and identify what different characteristics the schedulers exhibit You can make the following assumptions enforced and caught by the reference program at most 10000 IO operations will be tested so it is OK recommended to first read all requests from file before processing all io requests are provided in increasing time order no sort needed you never have two IO requests arrive at the same time so input is monotonically increasing I strongly suggest you do not use discrete event simulation for this lab You can write a simple loop that increments simulation time by one and checks whether any action is to be taken In that case you have to check in the following order The code structure should look something like this there are some edge conditions you have to consider such as the next or more than the next I O is for the track the head currently is at hence the seek time is 0 and you have a loop somewhere etc while true average turnaround time per operation from time of submission to time of completion average wait time per operation time from submission to issue of IO request to start disk operation maximum wait time for any IO operation if a new I O arrived at the system at this current time add request to IO queue if an IO is active and completed at this time Compute relevant info and store in the IO request for final summary if no IO request is active now if requests are pending Fetch the next request from IO queue and start the new IO else if all IO from input file processed exit simulation if an IO is active Move the head by one unit in the direction it is going to simulate seek Increment time by 1 When switching queues in FLOOK you start going up again then down until empty and then you switch queues again While other variants are possible I simply chose this one this time though other variants make also perfect sense Programming Assignment 4 Lab 4 IO Scheduling Professor Hubertus Franke CSCI GA 2250 001 Spring 2026 Additional Information As usual I provide some more detailed tracing information to help you overcome problems Note your code only needs to provide the result line per IO request and the SUM line The reference program under hf44 Public lab4 iosched on the cims machine implements three additional options v q f to debug deeper into IO tracing and IO queues The v execution trace contains 3 different operations add a request to the IO queue issue an operation to the disk and finish a disk operation Following is an example of tracking IO op 18 through the times 1151 1307 from submission to completion 1151 18 add 221 18 is the