CST334: Operating Systems, Week 7

 Identify the topics we covered in class -- you can start by listing them

• I/O Devices
• Hard Drives
• Files and Directories
• File Systems (Data)
• File Systems (Access)

Explain what each of the topics were in your own terms -- take the identified topics and add a sentence or two describing them

I/O Devices

This topic focused on how the operating system interacts with hardware devices in a controlled and efficient way. Devices expose simple interfaces that the OS can read from or write to, and techniques like polling, interrupts, and DMA are used to coordinate work between the CPU and slower hardware. The main takeaway for me was that I/O design is largely about avoiding wasted CPU time while still responding correctly to device events.

Hard Drives

Hard drives were examined in terms of their physical behavior and performance costs. Breaking disk access down into seek time, rotational delay, and transfer time helped explain why access patterns matter so much. Sequential access being dramatically faster than random access now makes sense, given how expensive mechanical movement is compared to data transfer.

Files and Directories

Files and directories are the abstractions that make persistent storage usable. A files is treated as a simple sequence of bytes, while directories map readable names to inode numbers. This model hides all of the physical disk complexity and allows users and programs to work with paths instead of worrying about where data is actually stored.

File Systems (Data)

This section focused on how file systems organize data and metadata on disk. Structures like the superblock, inode table, data blocks, and bitmaps all work together to track what exists, where it lives, and what space is free. Seeing these structures laid out in a simple file system made it easier to understand how files are created and managed behind the scenes.

File Systems (Access)

File system access covered how system calls like open, read, write and Iseek are translated into actions on those on-disk structures. The idea of per-process file descriptors pointing into a system-wide open file table clarified how offsets, permissions, and file state are tracked. This helped connect user-level code to what the OS is actually doing internally.

Identify least-understood topics -- of these topics, which was the hardest for you to write the descriptions?

The hardest topic for me to fully explain was hard drive behavior, especially how seek time and rotational delay interact during real disk access. While I understood each component individually, combining them into a single mental timeline required more effort than the other topics. 

Explain the nature of your confusion -- for these difficult topics, what pieces of them make sense and what pieces are difficult to describe?

I understand that the disk head must move to the correct track and then wait for the desired sector to rotate underneath it. What was less intuitive was reasoning about how much time each step contributes depending on where the previous accesses occurred. Without diagrams, it was harder to picture how small changes in access patterns can significantly affect performance. 

Identify "aha" moments -- which topic did you find it easiest to write about, and why did it make sense?

Files and directories were the easiest topics to write about because they connect directly to things I already use. Understanding that directories are just mappings and that files themselves have no inherent structure beyond bytes helped simplify the entire system. The explanation that lseek only changes an in-memory offset, rather than causing disk I/O, was a particularly helpful clarification.

Another “aha” moment came from the file system layout discussion. Once I saw how the superblock, bitmaps, inodes, and data blocks fit together, file operations felt much more mechanical and predictable instead of mysterious.

Ask questions -- what do you think will come next? Are there any gaps that don't seem to be explained yet?

Since this is the final week of the course, this section feels more reflective than forward-looking. One remaining challenge for me is confidently tracing the full path from a high-level file system call down to the physical device behavior without relying on diagrams. Each layer makes sense on its own, but mentally simulating the entire process end to end still takes effort. This week emphasized the importance of building a complete mental model that connects hardware behavior, OS abstractions, and application-level code.

What connections do you see to other classes and applications -- have you used/heard/thought about these topics before?

The disk timing analysis connected strongly to computer architecture concepts like latency and throughput. The file descriptor and resource-tracking discussions also tie back to C programming, where careful management of memory and handles is critical. More broadly, the file system abstractions reinforced the same ideas seen earlier in CPU and memory virtualization: the OS exists to hide complexity while still respecting the constraints of the underlying hardware.