Filesystem and Storage

Filesystem and Storage

Purpose

This page describes the minimal storage plan for OSAI.

Contents

• Storage Layout
• QEMU First
• System Image
• App Data and Worktrees
• Rollback

Storage Layout

The initial storage plan includes:

• boot partition;
• system image;
• app data;
• repository worktrees;
• build artifacts;
• logs and telemetry;
• rollback snapshots.

Keep these domains separate:

Domain	Purpose	Isolation rule
Boot partition	UEFI loader and early kernel payload	Read-only after boot where possible
System image	Kernel, userspace, runtime services	Signed update path
Model files	CPU-only AI weights and metadata	Read-only mappings into model arenas
Source repos	Application Git repositories	Access controlled per embedded app agent
Worktrees	Agent-specific patch workspace	One worktree per agent/session
Build output	Compiler and test artifacts	Never mixed with source or model arenas
Logs	Audit, boot, test, benchmark output	Scrub secrets before persistence

QEMU First

QEMU uses VirtIO block first. GPT parsing and a simple read-only filesystem are enough for early boot.

System Image

The system image should be reproducible and generated from scripts. Build artifacts belong in build/, out/, or another ignored output directory.

App Data and Worktrees

Each app agent should use explicit worktrees and build output directories. Build artifacts should not contaminate source trees.

Rollback

Snapshot and rollback are required before code-changing agents can safely modify running services.

Patch failure behavior:

• failed build/test keeps the worktree for review and does not commit;
• failed deploy rolls back to the previous known-good service image;
• Git conflict blocks commit/push until resolved;
• storage error drains the affected AI Cell and preserves logs.

Hardware Direction

NVMe is the first real storage target after VirtIO. Queue ownership and NUMA locality matter for Intel Xeon.

Related Pages

• App Agents
• Security Model
• Driver Model