00~move the writable upper to disk instead — likely via virtio-fs sta…

[Lucky Abolorunke (Oneimu)]

[POC}

The problem we're trying to solve

Substrate runs AI agents inside tiny virtual machines (micro-VMs). Each agent thinks it has its own computer with its own disk. But here's the catch: that "disk" is
fake — it's actually the VM's RAM. Every file the agent writes (logs, downloaded packages, code checkouts) is really sitting in memory.

That was a deliberate choice because it's fast, but it has two costs:

1. RAM is expensive and limited. An agent that writes 2 GB of files eats 2 GB of RAM. Substrate's whole business is packing many agents onto one machine — RAM-hungry
   agents ruin that math.
2. Snapshots get fat. When Substrate "pauses" an idle agent, it saves the VM's memory to a file (a snapshot) so it can resume later. If the memory is stuffed with
   file data, snapshots are bigger, and pausing/resuming gets slower.

Ben's suggestion: what if agent file writes went to the host machine's actual disk instead of RAM? Disk is cheap and plentiful. The catch: disk writes are slower.
Nobody knows yet if the trade is worth it — that's your investigation.

What we just built

A switch. The runtime now has a flag with two positions:

• --rootfs-writes=memory (the default, unchanged): file writes go to RAM. Fast, expensive.
• --rootfs-writes=disk (new): file writes go to a folder on the host machine's disk. The VM reaches that folder through a "pass-through window" called virtio-fs — a
  standard mechanism for letting a VM read/write a host folder. Conveniently, Substrate already used this exact mechanism for another feature (durable volumes), so we
  copied a proven pattern rather than inventing one.

[Benjamin Elder (BenTheElder)]

Snapshots get fat. When Substrate "pauses" an idle agent, it saves the VM's memory to a file (a snapshot) so it can resume later. If the memory is stuffed with

Actually, for "full" snapshots this remains true, and we do not have a "process memory only" snapshot mode currently, we decided to discard that.

A switch. The runtime now has a flag with two positions:

I think we should commit to one and revisit later if needed. gVisor sandboxclass does not expose similar knobs and this could get out of hand.