CPU ram process simulation . Pure c . visualization and compare performance of multiple scheduling algorithms . SRTF | FCFS | SJF | RR | PPP | PPN.
Overview
atlas-fs exists because reading about the VFS only goes so far. Implementing
lookup, getattr, and readdir against a real kernel forces every vague
mental model into a concrete decision: what is an inode here, what is a path, who
owns a reference.[1]
The mounted tree exposes the knowledge base itself: /articles/vfs-path-resolution.md
is a real file, and its engineering relations appear as symlinks under
/.relations/. The filesystem is the interface — which makes this project the
natural testbed for everything in the path resolution article.
Architecture
One process, one thread for the FUSE session, no async.[2] The inode table is the interesting piece: the kernel asks by inode number after the first lookup, so the table must be stable for the mount's lifetime. That constraint came straight from the inode lifetime rules.
Decisions
Future work
- read-only mount with stable inode table
- lookup entry caching with conservative TTLs (ADR-003)
- relations as symlinks under /.relations/ (ADR-004, proposed)
- invalidation on content change — kernel notify support
- benchmark against dentry-cache notes methodology
References
- 1Documentation/filesystem/fuse.rstThe Linux kernel community · 2024
- 2fuser — a Rust library for filesystems in userspaceChristopher Berner and contributors · 2024