Implement Copy-on-Write Filesystem for Snapshots

Snapshot-Friendly Storage

Copy-on-write filesystems (ZFS, btrfs snapshots) never overwrite live blocks; they write new blocks and update pointers, leaving old trees reachable for snapshots.

Snapshot Mechanics

On write to snapshotted file:

• Allocate new data block
• Copy-on-write metadata path to root
• Snapshot inode still references old tree

For example, volume at snapshot S0 shares 90% of blocks with live tree; after heavy writes, shared ratio drops as new branches diverge.

Why This Matters in Production

Btrfs, ZFS, and Apple's APFS all use exactly this copy-on-write-plus-reference-counting design to make snapshots instantaneous and clones nearly free, which is why zfs snapshot and Time Machine local snapshots return immediately even on multi-terabyte volumes. Forgetting to check the reference count before an in-place write is exactly the bug class that would corrupt a snapshot that's supposed to be immutable.

Debugging Checklist

Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.

Implementation Notes

Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.

For This Exercise

You will implement COW block pointers and create read-only snapshots referencing older roots. This exercise requires proving reads from an old snapshot see historical contents after live file changes.