cd week_seven

Journal Entry Week 7

This week we started looking at how computers actually deal with real-world stuff like disks and devices, and then ended up inside how file systems are built from scratch.

Topics We Covered

• I/O Devices (how the OS talks to hardware)
• Types of devices (block vs. character/stream)
• Polling, interrupts, and DMA
• Device drivers
• Hard drives (structure + performance)
• Disk scheduling (SSTF, elevator/SCAN)
• Files and directories (what they actually are)
• Inodes and links (hard vs symbolic)
• File system implementation (vsfs, bitmaps, superblock, etc.)
• How file access actually works (step-by-step reads/writes)

Explaining the Topics

I/O devices are basically everything that lets the computer interact with the outside world—keyboard, disk, screen, etc. The OS doesn’t talk to them directly in a messy way—it uses a structured system with registers (status, command, data) to communicate.

There are two main device types:

1. Block devices (like hard drives) --> you can jump to any location
2. Stream/character devices (like keyboards) --> data just flows, and if you miss it, it’s gone

Then we learned different ways the OS interacts with devices:

• Polling = constantly asking “are you done yet?” (fast but wasteful)
• Interrupts = device tells the CPU when it’s done (more efficient)
• DMA = hardware just handles the transfer itself (best for large data)

Hard drives were kind of wild. They’re physical, spinning disks, so performance depends on:

• moving the arm (seek time)
• waiting for the spin (rotation delay)
• actually reading data (transfer time)

That’s why sequential reads are WAY faster than random ones.

Then we moved into file systems. A file is just a linear array of bytes, and a directory is basically a mapping of names to inode numbers. The inode is where all the real info is stored (size, location on disk, permissions, etc.).

The vsfs system helped tie it all together. It showed how disks are organized into:

• superblock (metadata about the system)
• inode table
• data blocks
• bitmaps to track free space
• Least-Understood Topics

The hardest part for me was honestly file system implementation and inode math.

I kind of get how:

1. inode number --> index into a table
2. then you calculate where it lives on disk

But when it turns into actual math (offsets, block sizes, etc.), I start to lose the big picture. I understand the idea, but the steps feel mechanical and easy to mess up.

Also, disk scheduling (like SSTF vs elevator) makes sense conceptually, but I feel like I’d struggle if given a complex example to solve.

Nature of My Confusion

What makes sense:

• Why sequential is faster than random (physical movement = slow)
• Why we need abstractions like files instead of raw blocks
• The general structure of a file system

What doesn’t fully click yet:

• Translating inode numbers --> exact disk locations
• When exactly different I/O methods (polling vs interrupt vs DMA) are chosen in real systems
• How all of this would look in actual code (especially drivers)

“Aha” Moments

• The biggest “aha” moment was realizing that files don’t actually have names.
• Directories are what give files names. Files are just numbers (inodes). That honestly changed how I think about everything in a file system.
• Also, the idea that deleting a file is just removing a reference (unlink) instead of instantly deleting data—that clicked really well.

Questions / What Comes Next

• How do modern systems (like SSDs) change all of this? Since they don’t have spinning disks, does scheduling still matter?
• How do real file systems (like NTFS or ext4) improve on vsfs?
• How does caching actually reduce all those disk reads we saw?
• Connections to Other Topics

This week tied directly back to:

• Virtual memory --> both use abstraction (pages vs blocks)
• Concurrency --> interrupts and DMA relate to CPU scheduling
• Data structures --> inodes, trees, bitmaps feel like DS concepts

It also made me think about real-world stuff like why copying files sometimes feels slow or why SSDs are so much faster.

Final Thoughts

This week felt like we finally saw how everything connects. Before, we were mostly dealing with CPU and memory (kind of abstract), but now it’s like “okay, how does data actually live somewhere permanently?”