Questions: I/O Management and Device Drivers

Question 1

A process calls write() to save a file. The call returns successfully. The system then loses power before fsync() is called. What happens to the written data?

• A. The data is safe on disk — write() only returns after the I/O operation fully completes to storage
• B. The data may be lost — write() returns when data enters the kernel buffer, not when it reaches the physical disk
• C. The data is safe — the kernel always flushes all dirty buffers to disk before returning from write()
• D. The data is safe — DMA ensures all memory-to-disk transfers complete synchronously with the write() call

Answer: (B)

Buffered I/O is a core feature of the I/O subsystem: the kernel copies data into an in-memory buffer and returns immediately, coalescing and scheduling actual disk writes for efficiency. If power is lost before the buffer is flushed, the data is gone. Option A is the most dangerous misconception — developers who believe it skip fsync() and then discover lost data only in production after a crash. The correct pattern for durable writes is write() followed by fsync(), which forces the kernel to flush all pending data to the physical device before returning.

Question 2

Why does DMA (Direct Memory Access) dramatically improve I/O performance compared to programmed I/O?

• A. DMA runs at a higher clock speed than the CPU, so it transfers data faster than the main processor could
• B. DMA allows data to transfer directly between a device and main memory without CPU involvement, freeing the CPU to execute other work during the transfer
• C. DMA bypasses the device driver layer, reducing the number of software layers the data must traverse
• D. DMA caches frequently accessed files in dedicated hardware buffers, eliminating the need to read from disk

Answer: (B)

Programmed I/O requires the CPU to execute a loop reading or writing one word at a time between the device controller and memory — simple but wasteful, since moving bytes is not what CPUs are built for. With DMA, the CPU sets up the transfer (source address, destination address, byte count) and then resumes other work. The DMA controller independently manages the memory bus and transfers the entire block, sending a single interrupt only when done. This is why a modern system can simultaneously stream video from disk, receive network packets, and run application code — the CPU orchestrates I/O without performing the tedious data-movement work itself.

Question 3

A bug in a device driver will crash mainly the specific process that was using the device at the time, since drivers handle device-specific operations in isolated user-space processes.

• T. True
• F. False

Answer: False

Device drivers run in kernel mode with full hardware access — not in isolated user-space processes. A driver bug can corrupt kernel memory, write to arbitrary hardware registers, or corrupt shared data structures. Because all processes share the kernel, a crashed or misbehaving driver can hang or crash the entire system. This is why driver code is disproportionately represented in OS stability bugs, and why operating systems like Windows and Linux invest heavily in driver testing and sandboxing techniques.

Question 4

The layered I/O architecture means that adding support for a new storage device requires writing only a new device driver, without modifying the file system, kernel buffering logic, or user-space API.

• T. True
• F. False

Answer: True

Layering is specifically designed for this property. The device driver is the only layer that speaks the device's specific protocol — register sequences, DMA setup, interrupt handling. The file system above it issues generic 'read block N' / 'write block N' requests and doesn't know or care whether those go to an NVMe SSD, a spinning HDD, or a USB drive. The kernel's buffering, scheduling, and error-handling logic operates on the same generic block interface. This separation of concerns is what allows the same ext4 file system to work on dozens of different storage devices.

Question 5

Explain why DMA is essential for modern I/O performance, and describe what the CPU does while a DMA transfer is in progress.

Model answer: Without DMA, the CPU must execute programmed I/O — a loop that copies each word of data between the device controller buffer and main memory, consuming CPU cycles on trivial data movement. DMA eliminates this: the CPU programs the DMA controller with source address, destination address, and byte count, then resumes executing other processes or handling other interrupts. The DMA controller independently arbitrates the memory bus and performs the transfer. When the entire transfer completes, it sends a single interrupt to notify the CPU. This allows the CPU to overlap computation with I/O, which is why modern systems can saturate multiple I/O devices simultaneously without the processor becoming the bottleneck.

The performance gain scales with transfer size. For a 1MB disk read, programmed I/O would require roughly 256,000 32-bit copy operations — keeping the CPU busy the entire time. DMA reduces this to one setup operation and one completion interrupt, freeing ~256,000 CPU instructions to execute useful work. This arithmetic explains why DMA is not optional for high-throughput I/O: it's the difference between a system that can handle concurrent I/O and one that stalls on every device transfer.