Implement In-Memory Filesystem Using Tree of struct inode

Trees of inodes

An in-memory filesystem models paths as a tree of struct inode nodes: directories point to children, files hold data blocks or inline buffers. No disk means you focus on naming, permissions, and lookup without driver noise.

inode Basics

Each inode stores:

• mode: file vs directory
• size and data pointer
• children map for directories

For example, path /etc/hosts walks root → etc dir inode → hosts file inode.

Why This Matters in Production

The inode/dentry split you build here is the same design Linux's VFS layer uses for every real filesystem, and it's exactly how tmpfs (the filesystem behind /tmp and /dev/shm) organizes files entirely in RAM. Get path resolution wrong and you reproduce real VFS bugs , like directory loops or dangling dentries , that have caused kernel panics in production.

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 lookup, create, read, and write on the tree API. This exercise requires enforcing that unlinking a directory with children fails, matching POSIX expectations.