I/O Management

CSS Optional — Paper-II, Section-A · P-II.III.VIII

1. Polling vs Interrupts

When the device raises an interrupt, the CPU suspends its current work and jumps to an Interrupt Service Routine (ISR) to handle it, then resumes.

2. DMA (Direct Memory Access)

For bulk transfers (disk, network), routing every byte through the CPU is wasteful. A DMA controller transfers data directly between the device and main memory, and interrupts the CPU only once — when the entire transfer is complete — freeing the CPU almost entirely from the transfer.

3. Buffering

A buffer temporarily holds data being transferred between a device and a process, letting computation and I/O overlap instead of running strictly sequentially.

• Single buffering: one buffer; producer and consumer of the data still can't fully overlap.
• Double buffering: two buffers — one is being filled by the device while the other is being consumed by the process, giving true overlap.
• Circular buffering: multiple buffers arranged in a ring, useful for streaming data (audio/video) with continuous production and consumption.

4. Spooling

Simultaneous Peripheral Operations On-Line — output (e.g. print jobs) is queued to disk first and a background process feeds it to the (slow) device at its own pace, so the requesting application doesn't block waiting for the physically slow device.

5. Disk Scheduling Algorithms

Since seek time dominates disk performance, the OS orders pending requests to minimize head movement.

6. I/O Hardware Overview

A device is controlled through a device controller (the electronics that operate a specific device type), which the CPU communicates with via a small set of device registers: a status register (readable — is the device busy/ready/error?), a control register (writable — tell the device what to do), and data-in/data-out registers (transfer the actual data one unit at a time). The OS's device driver is the software layer that knows how to speak a specific controller's register protocol, presenting a uniform interface upward to the rest of the kernel.

7. Kernel I/O Subsystem — Services Beyond Individual Drivers

• I/O Scheduling: maintaining a per-device request queue and choosing a servicing order (e.g. the disk-scheduling algorithms above) to improve overall performance/fairness.
• Buffering & Caching: buffering (covered above) copes with speed mismatches between producer/consumer; caching keeps a copy of frequently-used data in faster storage to avoid repeated slow-device access — related but distinct (a buffer may hold the ONLY copy of in-transit data; a cache holds a COPY of data that also exists elsewhere).
• Spooling & Device Reservation: spooling (above) for devices that can't usefully be shared moment-to-moment (printers); device reservation gives a process temporary exclusive access to a whole device.
• Error Handling: the kernel retries transient failures, reports persistent hardware errors, and isolates failures so one bad device doesn't crash the system.

8. RAID (Redundant Array of Independent Disks) — storage management CSS often tests alongside I/O

RAID combines multiple physical disks into one logical unit for better performance and/or reliability, using striping (spreading data across disks) and/or redundancy (parity or mirroring).

Exam angle: a question naming a scenario ("a database server that cannot tolerate any downtime" vs "a video-editing workstation wanting maximum raw speed with backups handled separately") is asking you to pick and justify a RAID level from this table, not just define RAID in the abstract.

---

🧮 Solved Numerical 1 — C-SCAN Average Seek Time (CSS 2022, 6 marks)

Q: Disk has 100 tracks (0-99), head starts at track 20 moving toward increasing tracks. Pending requests (arrival order): 18, 25, 73, 46, 9, 92. Find average seek time using C-SCAN.

C-SCAN services increasing tracks to the end (99), jumps to 0, then continues upward.
Requests ≥ 20 (ascending): 25, 46, 73, 92 → then to 99 → jump to 0 → requests < 20: 9, 18

Head path: 20 → 25 → 46 → 73 → 92 → 99 → 0 → 9 → 18
Movement:  |25-20|=5, |46-25|=21, |73-46|=27, |92-73|=19,
           |99-92|=7, |0-99|=99 (wrap jump), |9-0|=9, |18-9|=9

Total head movement = 5+21+27+19+7+99+9+9 = 196 tracks
Requests serviced = 6
Average seek = 196 / 6 ≈ 32.67 tracks/request

Answer: ≈32.67 tracks per request (multiply by a given ms/track figure to convert to time, if provided).

🧮 Solved Numerical 2 — Buffering Reduces Running Time by at Most a Factor of Two (CSS 2023, 8 marks)

Q: Let C = compute time and I = I/O time per unit of data, over n units. Show buffering can speed up a program by at most 2×.

Unbuffered (strictly sequential): T_unbuffered = n(C + I)

Buffered (compute and I/O overlap): the bottleneck is whichever of C or I is larger, since one
of the two activities can never be fully hidden behind the other:
                                    T_buffered ≥ n · max(C, I)

Since max(C, I) ≥ (C + I) / 2 always (the max of two non-negative numbers is at least their average):
                                    T_buffered ≥ n(C + I) / 2 = T_unbuffered / 2

Answer: buffering can reduce running time by at most a factor of 2, and this bound is achieved exactly when C = I; buffering can never do better because one of the two activities must still occur n times regardless of overlap.

🧮 Solved Reasoning — Why "Favor Recent Low CPU Usage" Scheduling Favors I/O-Bound Programs Without Starving CPU-Bound Ones (CSS 2023, 10 marks)

An I/O-bound program uses the CPU only in short bursts between (longer) I/O waits, so its recorded "recent CPU usage" stays low — a scheduler favoring low recent usage naturally prioritizes it, which keeps I/O devices busy and improves throughput/responsiveness. CPU-bound programs aren't permanently starved because the "recent usage" measure typically decays/ages over time (periodically halved), so a long-waiting CPU-bound program's recorded usage falls and its priority eventually rises again — the scheme is self-correcting.

---

🎯 CSS Exam Angle

I/O Management questions often ask you to prove a bound (Numerical 2) rather than just define terms — show the inequality chain explicitly, since the proof structure itself carries marks independent of the final numeric answer. For disk-scheduling numericals, always state the head's starting direction and full path before computing movement, and double check whether the question wants SCAN, C-SCAN, or LOOK — these are frequently confused.

📌 Past CSS Paper Frequency

⚠️ MCQ Traps

• Polling is not "always worse" — for extremely high-frequency, low-latency devices it can beat interrupt overhead; don't answer "interrupts are strictly superior" as a blanket statement.
• DMA interrupts the CPU once per whole transfer, not once per byte/word — that's the entire point of DMA.
• C-SCAN's return jump services nothing — it's a pure repositioning move, unlike SCAN which continues servicing on the way back.
• max(C,I) ≥ (C+I)/2 is the crux of Numerical 2's proof — memorize this inequality step, since restating it is worth marks on its own.
• Buffering and caching solve different problems — buffering copes with speed mismatch on data in transit; caching avoids re-fetching data that already exists elsewhere. Don't use the terms interchangeably in an answer.
• RAID 1/10 sacrifice capacity for redundancy; RAID 5/6 sacrifice write speed (parity overhead) for a better capacity/safety balance — a scenario question expects you to weigh this trade-off, not just recite RAID definitions.

📜 Past-Paper Questions & MCQs (CSS 2016–2026)

2022 · Paper-II · Q2(b) · 6 marks

Q. The disk head is at track 20, moving towards higher tracks. The disk has 100 tracks (0–99). The requests in arrival order are 18, 25, 73, 46, 9, 92. Using C-SCAN, find the performance in terms of average seek time.

Ans.

• C-SCAN serves requests in one direction only. At the end of the disk the head jumps back to the start and continues in the same direction.
• Service order: 20 → 25 → 46 → 73 → 92 → (to the end, track 99) → (jump to track 0) → 9 → 18.

• Total head movement = 5 + 21 + 27 + 19 + 7 + 99 + 9 + 9 = 196 tracks. The average seek = 196 / 6 ≈ 32.7 tracks per request.
• If the return jump is not counted (it is a fast, non-service move), the total is 97 tracks, an average of about 16.2 tracks per request.
• To get time, multiply by the seek time per track.