What File Systems Solve

A file system organizes raw blocks of a storage device into a hierarchical name → bytes mapping.

Without an FS, a disk is just a sequence of 512-byte (or 4 KiB) sectors. The FS adds:

• Naming: paths like /home/alice/notes.txt.
• Hierarchy: directories within directories.
• Metadata: size, owner, perms, timestamps.
• Allocation: which blocks belong to which file.
• Crash safety: don't lose data on power loss.
• Concurrency: multiple processes accessing safely.

Real file systems:

• ext4 (Linux default).
• xfs (RHEL default for many years).
• btrfs, ZFS (COW, snapshots, RAID).
• APFS (macOS), NTFS (Windows).
• FAT32, exFAT (USB drives, embedded).
• F2FS (flash-friendly).

Educational: ext2 is simple enough to grok. We'll model on that + xv6's FS.

Layered architecture:

[Application]
  ↓ open/read/write/close
[VFS layer]   (POSIX abstraction over many FS types)
  ↓
[ext4 / xfs / btrfs ...]
  ↓ block I/O
[Block device]
  ↓ SCSI/NVMe/SATA
[Physical disk]

Key tradeoffs:

• Block size: 4 KiB common. Larger = better throughput, more wasted space.
• Inode size: 128/256 bytes. More space → larger pointer tables.
• Allocation policy: where to put new files (locality).

We'll build a tiny FS: superblock + bitmaps + inodes + directories + simple file ops. ~1k LOC.