Phase 13

Writable FS

Allow processes to create, write, and delete files so the OS has persistent and ephemeral mutable storage. A RAM-backed tmpfs provides scratch space; FAT32 gains write support for persistence across reboots.

Complete

Learning goal

Understand the difference between a page-backed in-memory filesystem and a disk-backed one.

Why this phase matters

How it works in m3OS

Phase 13 adds a writable in-memory filesystem (tmpfs) mounted at /tmp and extends the Linux syscall ABI with file-mutation operations. Userspace C programs compiled with musl can now create, write, read, and delete files using standard POSIX calls.

How it builds on earlier phases

This phase builds on POSIX Compat and turns that foundation into Writable FS.

Implementation outline

Add a WriteableFs trait to the VFS server alongside the existing ReadableFs.
Implement tmpfs as a hash map from path to page list; no disk involved.
Mount tmpfs at /tmp during init; verify read/write round-trips.
Add the FAT32 write path: allocate clusters, update the FAT table, write directory entries.
Add fsync as a no-op on tmpfs and a flush call on FAT32.
Expose write-oriented syscalls through the POSIX compatibility layer.

Task progress snapshot

No checklist tasks were discovered for this phase yet.

Documentation targets

Documentation deliverables have not been listed yet.

Deferred follow-on work

page cache and write-back buffering
journaling or copy-on-write crash recovery
file permissions and ownership bits
hard links and symbolic links
mmap of file-backed pages
extended attributes

Source materials

Important code

Code spotlight cards

Key files

How real OSes differ

Production kernels use a page cache that unifies file data and anonymous memory, deferring writes to disk with periodic background flushing (pdflush/writeback threads). FAT32 on real systems is wrapped in transaction layers or replaced entirely with journaling filesystems (ext4, APFS, NTFS) to survive power loss. This phase writes through immediately and accepts the corruption risk, which is fine for a single-user development machine running in QEMU.

Success criteria

A program can create a file in `/tmp`, write text into it, close it, reopen it, and read the same text back.
A file created on the FAT32 partition survives a reboot and is visible to the host.
`unlink` removes a tmpfs file and frees its pages.
Directory creation and removal work on both backends.
Writing past the end of a FAT32 file allocates new clusters correctly.

Related phases

Keep exploring the roadmap

POSIX Compat

Implement enough Linux-compatible syscalls and bundle musl libc so that ordinary C programs compiled on the host can run unmodified inside the OS.

Shell And Tools

Turn the minimal shell from Phase 9 into a genuinely useful interactive environment: pipes, I/O redirection, job control, environment variables, and a small set of core utilities that exercise the filesystem and process model.